 Hi everyone, today's a regular Google Summer Report office hours, on one of the day-to-day this is February 12th, Mark E. Jackson is unable to run the today's session, he's busy, so please buy with me. And we have a lot of people on the call, we have several students, we have a lot of potential mentors, so we will run a common agenda, we will start on short call me by students who just joined to ask a few questions, then we will discuss application, status, and other open action items. And then we will have call me section for longer questions, if you have any. So that's the idea. If anyone wants to add additional topics, just make suggestions in the Google Doc. The Google Doc is based in our Gitter chart, so you can just open the link and make your suggestion. It should be publicly available for everyone. Okay, so that's the plan. Let's begin. Does anyone have any short questions, which we couldn't discuss in the beginning? So, for me, I've been delighted to have submissions from students of pull requests to repositories. That's been really great. I assume that's a good pattern, and we want to keep encouraging that. Can you confirm that? That that's a good way for them to get started, to pick up a newbie-friendly bug and submit a pull request so that they learn how the project interacts? Yeah, that's why we post a newbie-friendly issue. So, that's the whole idea there. So, anybody who's reading project descriptions, you can follow the links. We have a newbie-friendly issue, which is specific to a particular project. And for all published, we at least provide some guidelines and preferable links. So, for example, if you want to work on git-pigging performance, you can find that there are something like 10 newbie-friendly issues. And you can pick them to study the code base and to publish your proposals. And if there is not enough newbie-friendly issues, we also have a link to the global page. Maybe we should replace this link because now we have more sources. But yeah, so this is one of potential sources of newbie-friendly tickets we put on tape. And yeah, if you're looking for something more, we have Jenkins IO Participate page. And there also we have newbie-friendly issues linked from different locations. So, for example, for code, you can find more links here. Newcomers, newbie-friendly issues in Jenkins Gila. So, basically the same link has been in our JSoc page. But yeah, we should probably link github issues, which we didn't do before. But now you can find that there are also some issues in github, which you could help us. Same for documentation, things you can find newbie-friendly tickets and some hints on these pages. Thank you. Thanks very much. Okay. Any other questions? We have our current Arici participant would like to mentor on Google Summer of Code. We think this is wonderful. We really welcome her contributions and her volunteering, her time. How do we go about announcing or formalizing that role for her? So, in the current stage, we don't have formal mentors. We have potential mentors. Okay. So, basically, it's a list of contributors who are interested in this project in some conditions. So, when you add yourself to a list of potential mentors, you don't commit to mentor a project. You don't accept, well, you don't make any kind of commitment, except the fact that students will be able to see your name and pin-puning the recommended channels. So, that's it. So, if anybody wants to join as a potential mentor to any project, just add your name to the list. That's it. So, submit a poll request to this page or to the matching page proposing your name be added as a mentor. Exactly. Or as a potential mentor. Yeah, great. So, we have, maybe we have Jenkins X. Ops. The second project was about Bootloader. Oh, it just doesn't have Jenkins X here. So, yeah. I'll probably submit the poll request. So, for example, let's take this project idea submitted by Kara. So, yeah, that is all the description. And if you want to add yourself as a mentor, or the quickest way to do that, just click on improve this page. And you will see our Skidog page with metadata. And you can add your Jenkins Chira ID here. Great. Yeah, it may require some additional steps, but yeah, because now it's based on authors. But yeah, if you just submit a poll request with update, we will be able to guide you. Okay. Any additional questions? I had a question. With respect to the Jenkins X project, do we need to keep discussions limited to the GSOC Gator channel or could we take the discussion to Slack? Which Slack? For Jenkins X? Yeah, for Jenkins X, you should definitely use Slack. So, they think here that Kara submitted a link to Jsoxy. So, Kara, maybe you would like to update it to the Slack reference. Okay. Oh yeah, I put it to the, I put the link to the original issue in the mailing list. But okay, I'll put the link to the for discussion to the Jenkins X Slack channels. Yeah. For Jenkins X, it might be convenient, especially if you have a special channel for Jsoc emitters or for Jsoc slash outreach slash other programs. Because if you just put a link to the developer's list, it may, to the developer channel, it may be a bit overloaded, but it's up to you. Okay. We don't currently have that channel. So, for now, we'll be the developer channel. And that Slack is actually the Kubernetes Slack. So, we'll look into developing another channel for mentoring programs. I think that's a very good idea, Oleg. Okay. Yeah, that would be great. So, if something needed to link site, please let me know. Because when we created this framework, we didn't have these cases for Slack. And right now, you can see here that you actually are why we get this link is because the metadata is more implicitly pulled because you don't have a right it. So, we probably need to make some changes to make it happen. Okay. Yeah, I'm just looking. Okay, let's take the coverage. It's a better example, because it takes metadata from SIP. What do we have? Plugging installation manager tools. So, here the chat link links to the special Gitter channel. And here how it's implemented just has links metadata. It means a link to Gitter. So, probably we could something like that or just a chat link which supports URL, because I guess what we need to put for Genkisex projects is a link which is listed on this page Genkisex slash community. So, we potentially need to just put a link to this location, right? Yes, that would be very good. So, yeah, I think it requires some programming. Okay, I had another question. With respect to the GitHub checks API, I think I suggested that we form a different Gitter channel to which we didn't follow up on that. So, is there any plan to create another Gitter chat or are we going to do those discussions in the GSOC channel as well? For each project? For the Gitter checks API? It depends on mentors. So, as long as there is not a lot of traffic, it makes sense to use a GSOC channel. What we what we usually do, we create channels when project ideas are separate. So, at that point, it's almost 100% probability that there will be a dedicated channel. But as a part of application, it's ultimately up to potential mentors and champions. They prefer to create another channel. Why not? Yeah, okay. Thank you so much. Yeah. So, here, I think it's fine to keep it as is. Now, I have a question regarding to Windows Server project. And is there any kind of a Gitter channel or something like for Windows Server project? Let me show it to you because yeah, so Windows services, you're open in here and there is link to chat and Gitter and it gives you to platform special interest group. So, this is the channel which is recommended for this project. Okay. Okay, thank you. Yeah. So, in the case of doubt, ask in the GSOC Gitter, but you try to point people to specific channels when it's possible. Well, and that's a good reminder that that that link on the project page is a trustworthy link. So, if we make a mistake in that link, we'll go correct it through poll request to Jenkins.io. Exactly. Okay. Any other questions? If not, let's continue. We will still have Kone at the end of the session. So, if you have any new questions, just let's postpone them to the end. There was a question from Mark about the timeline. So, I will just put it in here. Okay, so today is February 12. So, we are somewhere between these phases. So, on February 5, we submitted our final application. Thanks a lot to everyone for participating in the reviews. This application is available on our website. So, basically, it's the same. And now we are waiting for Google to make final decision where we accept it or not. This decision will arrive on February 20. So, after that, we will know that we accepted and that we will get at least one project slot. So, basically, it means that Google Summer of Code for Jenkins happens. And then we'll start all the prep work. So, there will be a lot more students reaching out because Google will publish the 2020 site with reference for participating organizations. Jenkins filled with it. There will be new project tags. It will be possible to discover Jenkins project. And hopefully, we'll get a lot more traffic. And then the most active part starts. So, until March 31, basically, there will be a lot of discussions with students. We already have several students who submitted their project proposal drafts. But there will be a lot more of them, hopefully. And our main objective in this period will be to just answer questions, provide some feedback in the project proposals, and to help students who are interested to do the submissions. So, this is the phase where we are not really proactive. We just handle a lot of requests. But at the same time, we need to ensure that all our project ideas are moved to the published state shortly after February 20. So, if you go to our current page, you can see that there is a lot of project ideas which are in drafts. Some of them are in drafts due to technical reasons because we need to convert them to a ski dog. Some because we are missing items. For example, if you take Jenkins X project ideas, we still need to have new beforehand issues etc. Oh, yeah, we already have them. So, we were missing the quick start guide. But it's a minor thing which can be delivered quickly and we can get this project published. So, I hope you'll be able to move the most of the projects to the published state by the end of February. And yeah, so that one month of discussions, these discussions will be quite hot in the last week especially because the land driven development as always. But yeah, after that, we will have a selection phase, which is one month. But it is one month is quite hot months for mentors and for students because we create mentors teams. So, basically, my mentors and students. So, this is where you will have communications with mentors with regards to their commitment, because we will expect all mentors who really need teams and who participate in teams who commit time to that. And it will be a part of our project mapping. And after that community bonding and coding. So, these phases we can probably discuss later. But yeah, the public part starts only in my process, a lot of work before it happens. Any questions? Okay. My question, I like follows on from what you've said and it's on the list further down with duplicate projects. So, both of the Jenkins X projects are in the proposed list and then one is duplicated in the still under discussion list. What does it take to move it out of that ongoing discussion list? It's just a single request. We should remove the file. Yes, what would you like to see in that pull request? Just removing the file. Just removing it. Yeah. So, how it's organized? Oh, right. Now I understand why it's a bit complicated here, because for this type, we just link the developer mailing piece. Okay, so let's take a look using another project. So, I'm just clicking improve this page to not go to GitHub, but you can see that we are on GitHub and there is a folder project ideas. So, each project has an entry here. For example, for Jenkins X, we have one, two, and this is probably one which needs to be removed. Yep. Yeah. So, this is metadata which was created by me. So, I will just delete this file. Jx, I don't know for duplicate. See, this is cool. Live GitHub, not just live coding, but live GitHub pull request creation. Yeah, that's fine. Unfortunately, we still don't have automatic labeling code. But yeah, it's trivial project. So, yeah, here we go. But yeah, if anyone wants to make some suggestion to project ideas and forward it with any other page on Jenkins IO, the full is more or less the same. You click improve this page and then you can modify it. Great. Thank you. Okay. Yeah, one action I can less. Okay. So, the next question was actually about incoming project ideas. So, right now we have, I don't have mouse. So, sorry. Okay. So, we are here. Now we have seven or eight project ideas which are fully accepted. So, it means that they fully match our criteria. We also have a bunch of project ideas here, which need additional actions. If I understand correctly, one of action items from the previous meetings was to move Jenkins REST API and other topics to the ongoing discussion list. Is correct, Martin? Yes, I'd like to move them off, but I don't know if we want to keep them somewhere. So, you think it's better to just kill them? Okay, just remove them. Yes, so removing them is the most straightforward way. Okay. Yeah. So, if there is no probability to get mentors there, yeah, we probably just remove them. Okay. And the way is to start the discussion and the developer may, please say that there are ideas which we would consider doing, but we don't have anyone interested. And then we move them back to ongoing discussion. But it's a more complicated step. I see. Okay. So, if you want to just start that thread in the developer may, please, I can modify the statuses. If not, let's just remove them. Okay. I'll let you know. Okay. So, what else do we have in the list? So, to make specific engineering. Bitbucket REST API is probably the same as others. Because EHQ is listed here. I pinged him whether he would be able to be a little mentor there, but I didn't get the response so far. So, I'll do my best effort. If not, we will remove further in the same way. Code coverage improvements, it stays. Polydocket images stays. The coverage probably stays in the print. Yes. So, we are for these ideas. We just need to move them to YAML, sorry, to ASCII doc from Google doc. Unfortunately, there is no straightforward integration. You can use Pandoc for that, but Google injects a lot of metadata, which needs to be manually removed from RAM export pages. So, it takes time. Yeah. For Jenkins X, I think we can do it quickly. For this one, we also have a plan. Okay. So, Oleg, do you want to convert all the Google docs to the A doc as pull requests and remove the Google docs altogether? It was my understanding of the current project ideas policy. So, I just interpreted how it's written right now, and my assumption was that it's required to migrate to ASCII doc to get the idea to the substitute list. Okay. If you think that we can just keep separate project ideas with Google doc, then it's a separate story. It could save us some time. Because it's what, some time? It could save us some time. To keep using the Google docs? Yes. Okay. So, I don't... My idea when I wrote this page that you are showing is not to forbid Google docs, it was to say it's optional. So, maybe that is not clear. So, Martin, just for... I'm trying to be sure I understand. I like the notion of having an A doc file as an idea that we have a record of, version controlled. Is your concern that that's too much overhead? I'm not sure I'm understanding your concern. The Google doc was really easy for us. It was really easy for students to provide... So, students and other mentors could comment on the Google doc without opening a couple requests. It was a very low barrier of entry to use Google doc to discuss the project ideas. So, that was the original intent, was to have a very low barrier of entry. Yeah. So, we can probably keep it as is, because while the rendering still works, the layout still works, probably we could kill metadata. Example three, it's no longer needed. Yeah, the problem that I don't have permissions, but yeah, that's why one of the reasons why keeping Google docs also becomes a kind of burden. There's drawbacks. Yes, that's one of them. You have to find the owner of the document. Yeah. So, but the rest is fine. So, if you agree that we keep Google doc as option for published ideas, I can proceed and publish maybe five project ideas right away. It's fine with me to continue to use Google docs. Any other opinions? Okay. So, I think we can just allow that you save some time. Okay. Thanks. Okay. That's all we had on the agenda, unless there are other open action items we needed to discuss. One item we had from previous months was student travel blog post. So, we've got one published this weekend is for a beauty blog. So, it's here. Trip to DevOps world. We also have one on the stage, the by-product chain. And if that's me. Yeah. But yeah, thanks a lot to a beauty and we definitely need more of these ones. So, one for by-product chain is already staged. I hope we will publish it maybe tomorrow or today, depending on the co-editors capacity. So, we are waiting for long. Okay. Any other action items we are missing? Okay. So, we can spend more time on coding and our chat was quite active. So, there was a question about automatic specification generator. So, I think we can press it. I'm having question about automatic specification generator. Can you hear me? Yes. So, last week I have worked on the open API and Swagger, which you have sent to me the links. And as you mentioned, I have done, I have queried the same thing in mailing list also. Martin Sir has given sources about Stabler. Can I know how can I start with? So, the most straightforward. So, what is the objective right now to explore the area or to start contributing towards the project? I want to contribute for a stable documentation automatic one. So, I have done the basics about how to generate from Swagger and open API, but how to make the process automatic? Yes. So, one of the things you could consider there, maybe as a first step. So, in Jenkins, we have some annotations provided by Stabler. So, for example, here there is export the notation. So, here you can see that there are two kinds of annotations. We can take, for example, okay, so, for example, if your browse change logs in Jenkins, you can also access them in REST API. Here you can see that the data container contains exported V, which basically sets an annotation that this class may be exported. And it also has some exported fields. So, for example, here items, kind, whatever it means. And what you could do as a first step to just create maybe a simple parser, which processes these annotations and generates skeleton Swagger output, because it would be one of the first steps for the project. And it's something which could help you to study how Stabler works, how annotations work. And how you can extend it. That means that whatever annotation we did that exported, are they, means, are they the request to the server? So, yeah, it's for good request. So, in Jenkins, yeah, I can just show an example. I have an instance. So, hopefully it was restarted after this. Okay, so we have a job here, which is quite old, whatever. And here you can see about the REST API. Where I gone? Okay, how do you define? This here? How fine it is. Yeah. So here, yeah, here you can just click JSON API, whatever. And you get a kind of output. So, this is an output which is basically a good REST API. And this output is generated by these exported annotations and other things. It doesn't cover all Jenkins REST APIs, but it's probably the case. I wish you can use for initial exploration because it's relatively simple. And you can just try pulling annotations and generating some machine readable documentation for that. As a first step. And one more query. It's like, we have to go through the code and we have to parse the, we have to get the exported functions and then we have to parse them and we have to generate the REST API documentation, right? Yes, something like that. So, it may be a bit more difficult because going through code. Yes, it's because the code won't be written as the same thing, right? Yeah. So if you're interested, there is, there are already some implementations. For example, we have parser which generates extension points, documentation Jenkins, and we also have parser which generates pipeline documentation. Probably I'll show you the second one. So Jenkins info and his pipeline. So pipeline steps doc generator. So again, it's a code which goes through plugins and generates some documentation. So for you, it could be a good starting point to see how a similar function is implemented. And you could try integrating it, for example, for sports operations. I will go to them and if I face any good news or loss. Does anybody else have comments about this project? I'm not sure whether Kristen is on the call today. Yeah, Kristen is online. Yeah, hey, I'm here. I don't really have too much to say. And one more thing is that will this project will be continued right if anyone, if I work on this. The low mentors for the STPA plugin. So there are mentors for the STPA plugins. It's me and Kristen, I believe. Yes. For this, you and Kristen were assigned as mentors. Yeah. So what it means, we are listed here as potential mentors. So we might be available for this project, but it really depends on multiple conditions like other applications, our capacity because everything may change in the next few months. So hopefully everything goes well. I believe that for this project, we can find more potential mentors. So if we get accepted on February 20th, we will be reaching out to Jenkins contributors to find more potential mentors. But yeah, I hope that this project happens because it's quite important to the Jenkins community. Yes, yes, yes, because it will do a overview about every plugin for processing or anything. Yeah. Okay. So I will work on this in this week and I will let you know what I have done my next week, next week meeting. Okay. Thank you. Any other questions? Thank you. That's all for now. I will ask. Okay. So this question is regarding to the Windows service wrapper. Here we are hoping to convert those XML password to YMS. So I think in other plugins as well, there are some XML implementation, I think in Rana, Ranae, process skill and share directory mapping and those things. So I think we are hoping to do kind of a full refactoring on Windows service wrapper or just convert them into ML. So for me, so, yeah, I would expect that this project still supports XMLs, but it gets additional support for YAMLs. So it's not something you replace one by another, but it's something to be discussed as a part of your proposal. Okay. Because if you can justify switching to YAML entirely, it can be discussed. And it's up to you to create this proposal. So project idea just narrows it to particular items, which would be nice to address, which would be improved. But your proposal may be quite different from the idea. And for this particular project, if you come up with something original, we still can consider that. Okay. So not fully aligned with the idea for YAMLs. Okay, thank you. Okay. Anything else for me? Thanks everyone. And let's meet again next week. If you have any questions in the meantime, you can use all the channels. So hopefully you'll have Jenkins X channel link properly in a few days. And for the rest, just keep your. Thank you. Thanks. Okay. Thank you. Thanks. Thank you everyone.