 Here we go. So, good morning, good evening, good afternoon, everybody joining to this Google Summer of Code 2023 at Jenkins office hours. So, just a word of introduction. Welcome to everybody interested in participating in Google Summer of Code. Thank you to be part of this great adventure. Just a little reminder, this office hour will be held every week. This time normally limited to half an hour. But these weeks will have more substantial meetings to answer questions and to give more details on projects. We're not going to spend too much time in general stuff, so I'll walk quickly through them. So, first important thing I'd like to share with everybody is that during this proposal time where everybody is competing by writing his proposal, we want a fair treatment of everybody. And this means that we're not going to engage in no mentor will engage in private discussions or answering private questions. Questions should be asked publicly and will be answered publicly. It's not that we are ignoring you. I receive invites. I don't want to ignore you at all, but some rules that we need to follow. So, in the same vein, all activities are public. Important is also the way we work in open source. No secrets. No will corner discussions in cabals. So, no, no, we work publicly. Don't forget also to have a substantial proposal, you need to exercise your GSOC muscle. Important thing is that you do a pull request, and especially in the domain where you want to apply, you need to have a good understanding how it works and also show that at least you can do the simple things or that you know the grammar of how things work and that you know how to do it. So, please exercise. Don't forget we'll have other Google Summer of Code. So, if you can't make it this year, we'll have other sessions. Once you have enough details and you know how things are going, that you know how to start writing your proposal, do it without waiting. And experience has shown, and I strongly encourage you, have your proposal reviewed by the community. It's a big step. You need to take a big breath and expose yourself. I know it's not easy, but it's part of the game. And so, write it. We're not there to judge your work. We're there to help you improve it and help you progress. Do that exercise as soon as possible. You will have the best proposal and the strongest one to compete. The last point I would like to do before getting to the hardcore agenda of this meeting is that this year there are a lot of people interested in participating to Google Summer of Code. This is great. There's a lot of enthusiasm and energy and is very rewarding for everybody. I just want to warn that we have only a limited capacity of mentoring projects, and this will make that we'll have to make decisions on how many projects will be able to field actually. There might be some reshuffling of the mentorship, and we're only going to choose the best proposal. So there is also the competition. This does not mean that you, as a candidate, are not good, are not worth it, or that you should change career reactions or things like that. Not at all. It's at this stage, it didn't work out. I'm open for discussions when the selection has been done to give personal advice to people and guide them on how they can prepare even better and use the time to learn about open source and get more up to speed and have a better chance to participate to Google Summer of Code. It would not be fun for me or us as org admins to have to tell people here you had a great proposal, but we had to choose and you didn't make it. So I apologize in advance for that, but we're together to build, and there will be great opportunities to continue help in learning and having other opportunities. This said, today we're going to talk about three project ideas, one being the plugin installation manager tool. The second one will be about building Jenkins.io with different or better tools. And the third one being screenshot automation for Jenkins documentation. So before we start, I just would like the mentors that are online in these meetings, either for these three projects or eventually for other projects to step forward, say a word and present. So I'm going to pick and then because I don't remember all the names, I know Mark Wait will be mentoring, is available to mentor one project and he's interested in several. So can you present yourself in a couple of words? Sure, I'm Mark Wait. I'm the maintainer of the Jenkins Git plugin. I'm a member of the Jenkins governing board. I've served in the past as Jenkins documentation officer. I'm part of the platform CIG. So I've got a lot of things that I find interesting in Jenkins documentation, Jenkins core, Git, and all those things mean that I've got far more ideas than I have time. And that means that I will, as John Mark said, mentor one project for Google Summer of Code, even though I've offered ideas for several. And I'm actually interested in even more than I've offered ideas. Thanks, John Mark. Okay, thank you. Who else is mentoring? I see Frayam. Yeah. Hi, everyone. I'm Frayam and I've been mentoring the plugin installation project. I'm actually here just to give guidance to all the new upcoming open source contributors because I feel that I have a lot to share here. I have a lot to share from my past two years of experience in open source and Google Summer of Code specifically. So I'm just here to learn and at the same time also teach others the ways of open source. This is fun for me. Yeah. Great. Thank you, Frayam. Bruno is Orga Admin and also is a potential mentor. Orga Admin wannabe, padawan, whatever. I'm just learning by looking at how you proceed as John Mark. And yes, potentially I could be a mentor for the mobile app building with Jenkins subjects. Two of them, one for Android and one for iOS, of course. And I've been an open source enthusiast for almost three decades now, but only started to work with Jenkins less than a year ago. And I can't wait to see what you're going to do with the Google Summer of Code this year. I've seen what you've done, what the other I've done the previous years and it was amazing. And I think it will be even better this year. Thank you, John Mark. Okay. Thank you. Now you need to help me a little bit. I see Mustafa. Mustafa seems to have connection issues. You're also offering to mentor. Hello. Hello, Mustafa. We hear you. Hello, everyone. You will join this year in screenshot automation for Jenkins documentation project. And I'm a software engineer. I have a lot of skills and I want to learn more. And I hope all of us gain a lot of knowledge this year. Thank you. Okay, great. And if I remember well, you're located in Egypt. Yeah, I'm located in Cairo, Egypt. I think my lead mentor currently will be engineer Mark White. Thank you. Okay, we'll see how things evolve because I was multiplying mentors. I did not manage to get there. Who else do we have here? I see Adrian. Yeah. Hello, everyone. So my name is Adrian. I've been in the Jenkins community for 10 years or more, even more now. I've been maintaining plugins. I've been helping people use plugins and Jenkins instances for more than more than 10 years. And now I'm working almost full-time on the plugins scoring project. And that's why I'm mentoring, I'm proposing to mentor two ideas on that subject, which we're discussed on Tuesday. So I won't maybe not repeat myself, but come back there. Okay, good. We have Chris. We have a lot of mentors, so I need to check the clock here that we don't go overboard. Chris is Orgi Admin. Go ahead, Chris. Yep. Hi, everyone. My name is Chris Stern. So I'm based in Hong Kong. And I'm one of the mentors for the building Jenkins.io with alternative tools project. And I've been involved with GSOC with Jenkins for about like for, I think for more than a year. And I was also a mentor at Orgi Mean Philosophy as well. And I think, so I have been a maintainer for some Jenkins plugins. Two of them, one is GitLab, and the other one is build timeout. And in my spare time, I'd like to go. Nice to meet everyone here. Okay, great. Now, who else is mentor in that I missed? Jake. I suppose I'm here, John Mark. Hello, everyone. My name is Jake. I work closely with Adrian on the plugin health scoring project. I was a mentor last year on that. Excited to bring those projects forward this year. Excited to see the contributions there. Jenkins has been working with Jenkins for the last two years, I think it's consumed my life. So yeah, looking forward to working with all of you. Continue like that, either you're losing your hair or you get all whites and gray. Yeah, I'm getting some gray ones. I'm catching up to you. Okay, great. Who else is mentor candidate or mentoring? Rajiv. Okay, yes. Go ahead. Yeah. Hello, everyone. So this is Rajiv. I'm a software engineer. I graduated last year. So I was a Jishak student with Captain project. And I think this is a time to contribute back to the community and mentor some people. So even the last year, okay, so I'm entering for the project, building Jenkins IO with alternative tools. And I think that why I chose this idea because last year, my idea was creating a dock engine for Captain. And this is like similar to almost similar to that project. And yeah, I'm happy to part of Jenkins org. Yeah. Okay, great. Thank you, Rajiv. First time I see you on the screen. So yeah, okay. This happens. I can't be everywhere. Is there another mentor? Yep. Yeah. Okay. Okay, yeah. So this is logi. So I'm a potential mentor for the exponential back off and Cheetah Ho agent reconnection this year. And I'm a former Jishak student from 2020. So I know how students are struggling to get into this Jishak at first. And so I'm here to help and learn with them. And yeah, happy to see you all. I can see some known faces. Yeah. It's great to meet you. Okay, logi, you're you're based where? I'm based in Sri Lanka. Sri Lanka. Okay, now I know here I have a poor memory and now I start connecting the dots. Great. Okay. Did I miss somebody else? Otherwise, we're going to I leave 10 seconds blank and then we'll jump into the technical subjects. Okay. Thank you, everybody for joining as mentors and especially as contributors and people interested in Google Summer of Code and in Jenkins. So thank you very much for that. And it's a good choice to be here. So we'll start with the first project idea of today, the plugin installation manager tool improvements. I think, Mark, you're going to present that one? I am. So if you're okay with it, John Mark, I'm going to go ahead and share my screen and use that as a framework for the discussion. That way people will have a record of where we went, etc. So the let's first do an introduction. What is the plugin installation manager tool? What it is, is a Google Summer of Code project from 2019. In 2019, we had this idea that we would really like to be able to replace or duplicate the features that are included in the Jenkins plugin manager inside the Jenkins product itself, inside the Jenkins war file. We wanted to duplicate that outside of Jenkins with all the capabilities it had, correct management of dependencies, correct handling of various things of version safety for Jenkins versions. And in 2019, that was implemented as a Google Summer of Code project. And like many things in the software world, it was useful, helpful, valuable, but still many, many things that could be done to improve it. And the idea here with this project idea is to invite you to review the issues, review the proposed enhancements, and suggest what you think would be ones you would like to attack, you would like to do as part of a Google Summer of Code project. You will need to learn more about plugin installation manager. You'll need to learn more about how Jenkins does plugins, right? There are concepts associated with Jenkins plugins which are rather different than other dependencies. And so you'll learn a number of things as you investigate this, make your proposal, prepare ideas, etc. So if we look at the issue tracker, and let's just look for now at enhancements, there are actually some bugs that may also be good things for you to consider. But for example, here's right at the very top, generate a plugins lock file from a list of plugins. So what this user is suggesting is they would like a way for the plugin installation manager tool to generate a prototype of its own configuration file based on existing directory. And it almost does it, but not quite. And almost is not enough. So this is one idea that might be included in a proposal. Now that's just one of many. And so there are lots of other ideas like, okay, let's retain the comments in the source file when we write an output as a destination. Sometimes I write things in my plugins.txt file which matter to me. And those things that I write, I don't want to lose. But when doing this round trip technique, I may lose those comments. So this is again an interesting and useful suggestion what to do with plugin installation manager tool, how to improve it. Proxy support is sort of a strong request for many people because many times they're sitting behind someone's corporate configuration. And that corporate configuration requires specialized proxy variables or specialized proxy username and password or some other novel or exotic thing. Each of those things could be a very, very interesting and useful addition to the plugin installation manager tool. As another example, okay, this one is one that I like because I spend a lot of time in Maven. Add a facility to take a POM file as input to the tool. So today what we have is we have, excuse me, okay, I successfully coughed without coughing in all of your ears. I'm proud. That's great. All right. So today we have several different input formats. I can use a simple ASCII text file, a simple text file that uses specifically formatted lines. I can use a YAML file with specific data format. What this is suggesting is, hey, give another idea of a way to use this input format, Maven, to do a proposal for I want this plugin. I want this plugin. Now there are some challenges hiding here as with any of these. A Jenkins plugin has an artifact ID but really the group ID. I'm not sure how relevant that is in this case because Jenkins itself doesn't honor. So interesting challenges here and useful things that would be added to the plugin installation manager tool. Now I've talked already probably more than I should have. Are there any specific questions that anyone wants to ask that we might dive into specific questions around plugin installation manager tool? I have one question just to introduce them. This project is with several elements. What is the advice you could give to contributors that would work on there? How should they handle their proposal? What would you expect to see in their proposal? What I would expect is a first an outline. Let's bring it up so that we've got an outline in their proposal that says, hey, I am going to do this thing and describing that I'm going to do improve the features of the plugin installation manager. They say and then they describe which features they selected saying I think we should choose this one and then this one and then this one and then this one and their choices should likely be given based on I think this is a good easy one to start and this one's more challenging and this one's very challenging and what that hints is they've done a little bit of exploration to understand something about each of those issues. Now some of them may say they may say I looked at this issue it was so easy while I was looking at it I just solved it and submitted the poll request. Okay good practice and we have several like that if we look there's an open poll request right now show security warnings by default. This one was a potential Google summer of code contributor who said I want to try something and started the poll request and I reviewed it gave some comments asked for some changes the changes have come back and now I've got to do another review that's what I get for taking time off so that is one way to you look at the issue list consider which ones are interesting include those in the proposal and prioritize them based on your perception of preferably hey this would be a good one to get started this one would be a good one to be sure that I understand it this one would be a good one that's more difficult and then maybe two or three at the end which say and here are some alternates in case one of these gets solved in the interim and did really show that the substance of the issue was understood and that you come already with I will tackle it that way that way this is the danger zone or the things that are unclear so it's not just listening issue one issue two issue three it's really discussing the issue and come with the plan is is that what you have in mind it is well and and one of the things that I as an evaluator of of project proposals will be doing is I'm looking for the technical technical content of the proposal that tells me that the person has done the research to be able to show that they can be successful doing this so I acknowledge this is this is real work and in fact the nice thing about it is for the Jenkins project as you do this real work you're actually helping the project even if ultimately you were not selected the things you've done the research you've done the investigation the study will have helped us move these things forward in some way okay great thank you for for your your lights shedding light on this are there questions from the audience about this project this tool is widely used it is okay and so that John Mark I think that's worth noting why why this matters to me and why it matters to the Jenkins project so the plugin installation manager tool is used very very widely because among other things it's bundled into the Jenkins container images so when a Jenkins controller at company XYZ is configured to use Docker they will typically configure it to use a very specific set of plugins and the reason they can do that is because of this tool so it's quite important to us that we not break this tool that we not do it do damage to it in ways that would be incompatible with its previous usage so we have to be conscious of and aware of compatibility somebody in the audience has questions it is also possible to ask questions through the Gitter the main Gitter channel there's no specific channel yet for this project so use the main goal sum of code SIG or use community.junkins.io which has a lot of benefit right of using we have two more minutes for that project so we're waiting for questions so so okay well in those two minutes I have to highlight a way that Chris and I did it Chris and I Chris Stern and I as part of a documentation office hours some weeks or months ago actually went through the list of of enhancements and we gathered ideas that we thought were interesting into this page by all means you can use our work where we thought these were interesting right by all means use those as suggestions one of them is already in progress but the others I think have plenty of things that plenty of opportunity for for ways to choose these and have them be positive so Mohammed Mohammed what's your question hello hi I'm Mohammed from Egypt okay I have a small question as it's my first time to join this Google summer of good should my proposal contains all this feature or I can pick one or more from these features very good question so so the way I interpret your question is should you should your proposal include this entire list if it did I would discount your proposal as not having not being a realistic proposal I don't expect any Google summer of code project could implement this entire list there's just too much work hiding in those things so you'll have to choose a subset or even items that may not be on this list your exploration will help you decide which items from this you should choose as part of the subset some of them are personally interesting to me plug-in version caching for container bills because I don't know how to do it it's a an interesting challenge error reporting probably an easy one to do those kinds of things so Mohammed did that answer your question yeah that's good because I work from three years and I believe that I can't finish all this feature in the target hours in Google summer of good I want to be realistic very good well and and you make a good point our initial proposal for this was that it would be a 175 hour project and 175 hours while that may sound like a lot in terms of the working world that's only four weeks of full-time work in the United States at 40 hours a week so it's actually not as much time as you might think over a summer it's about 20 hours a week for three months but it's not this is not a huge amount of time so you will have to choose a subset don't forget that there is documentation that's required there are some meetings their discussions so uh testing writing tests doing code reviews from other people's proposals yeah there are all sorts of things that that will make make the that will fill the time for the google summer of code project certainly so definitely choose only a subset of those ideas and choose the ones that you think would be most valuable part of that learning process reading the issue descriptions trying to understand them exploring experimenting with it will help you understand how people use this tool now and why they would care about these different things why would they want increased logging for debug and diagnosis and then you read some some comments from people behind odd firewalls and oh that's why those kind of things john mark i'm sorry i've gone over your time boundary a little a little bit but uh we we have a little bit buffer because these are general uh questions so i propose that we stop now discussing that if we have time over at the end of this session we can open it to all projects so the next one is building Jenkins IO with uh better tools who's going to talk about that one um should i yeah chris that'd be great go ahead great go ahead and you want me to stop sharing chris so that you can share are you okay if i navigate oh you can share your screen yeah it's i'm just going to look at this page anyways it's like um um let's see so let's maybe uh go to um yeah that's good that's good like one is good so uh for this project um the main purpose is to replace austrian which is the tool we're using to build ascii dogs sources uh from hamlet templates and the embedded files so uh one of the tools we are considering using for this project it's called entora but uh the thing with entora is that it's um the back end part it's quite easy the hard part it's for the front end so it's like uh to make it look like to to make the site look like what we have now for Jenkins IO it may take a while to uh to get um the layout and the visuals uh like really perfect and uh maybe maybe as you go to the github issue five four seven four so if we had to that issue we should be able to see if we um um if it's going down a bit to i think to a bit down yeah right here so we see uh if you look at the four links provided by basal um these are the prototypes for what he has tried before to um so essentially what basal did was he spent i think according to what he told us uh a while back before he spent a couple hours doing lunchtime to come up with a prototype uh just for user handbook alone if my memory is accurate but um we can see here uh besides user handbook we also have dog's site yep that one did i open the wrong oh yes okay right right but it's like um that that's the one that's not rendered that's the source code so if we look at this one we uh and maybe oh yeah that's kind of like uh we can see a handle file here yeah a handle file here uh but um if we go back to uh maybe so i think it's uh let's try this one all right yeah so i think are you trying to show the the render as versions because here's here's render as versions this is stable 2361 and here's master yeah but i'm trying to go to um maybe we should go to the source code to modules to modules to uh back to what you had before not this one just this one yeah this to modules okay ah got it yeah so it's like uh these are what we have currently on the Jenkins style website but if we click on i think if we click on one of these say uh blue ocean and then we go to yep we should be able to see like all these files are a dog's which means that they're ascii dogs so if we go back to say um maybe go back to uh let me think so modules and read let's see what they have there so we can see a like a dog's again page again because like um and maybe we should go to pages yeah and a dog's so basically like for the new version of the website it will be all in a dog's and maybe possibly demo files but no hammer files as we currently have now because like uh i think it's because like ostrich uses ruby and ruby it uses him hammer files as template but um that will no longer be the case here i'm saying this is uh i'm saying this because like someone did mention did ask about this um on get to before so um that and and it's like if we go back to the project idea page yeah if we go uh to let's say i think it's um quick start so that's a section called page content sources so if you look at this so what we're going to keep is ascii dogs web components but maybe no hammer or ruby and so so chris one of the challenge is there so that's that's focused intentionally on the user handbook right where the user handbook we think can be generated without needing the custom custom things that are in the hammer files whereas developer handbook i know is dependent on it and security advisories these all depend on it so so it's effectively this project is not just a generate the site using antora it's separate the site into more more broadly separated components where user handbook becomes its own component and is version specific but the others don't right so so this this is quite a for me a challenging project and uh uh an interesting challenge in terms of uh how do you do this and how do you make sure that it works yeah true and also there's like uh this project can be split into three parts so originally it's planned for 175 hours but it can be it can be pushed to 352 depending on how it contributes it's going to plan out like what scope what the scope will be for the final product so it could be uh but the most basic part we need to work on this user documentation with versioning and for the second part would be the developer documentation the one you mentioned before which strongly depends on the handbook files as templates but we have to if if we're going to stay with antora we have to come away to uh to rebuild that as well so as to remove the dependency on the handle files and the third part it's to build the block using gatsby so now would you be okay if if is there is there a is there a reason for gatsby after developer documentation with antora is that because having previous experience with antora it's a logical thing to do the next thing with antora i think so yeah that would be a good plan anyways but um the most important thing is to have the first part so uh the user documentation the second part i think we can we can have like uh the block two depends um but um or the developer documentation that that is the ordering for the second and third is as important great and if we can go down to quick start so for to start this project it's recommended to find some good first good issues in the janken style repo and to like uh yep but i think like for now we we have like we still have some good first issues so it's like um maybe maybe we can open some more later on but it's like um but it's easy to spot where there might be some improvements to be done on the janken style website so we welcome any ps to people's website as well so people understand the process yeah yeah yep so next besides like uh submitting a good uh pr would be to explore the janken style rl components repo that that part it's separate from the janken style web repo because like um this repo is uh for all the web components that we see um um that um includes the header fooder in our components as well across different janken style sites yeah so chris are you okay if i open up the example to show what this one is just so people are aware so when i open up jankins.io here's the page that's presented to me right this looks like a single unified site and when i click on documentation and go to one piece oh it's still the same top level header it still has the same footer on it now when i go to plugins oh hey the header is slightly changed but same content in the header and same content in the footer because it's using a web component for the header in the footer and so so the benefit of that header and footer technique is and as we split this site as this site becomes more and more components so if blog eventually becomes generated from its own uh set of repositories its own tools it will still have the same look and feel because of these top level web components okay uh mark and chris i'm going to pause for a second because i need to keep the things on on on the rails here so thank you very much uh before going to questions on that topic uh if contributors have specific questions and they don't feel that it's not working efficiently to get the answer or to discuss ideas on gitter or community.jankins.io you can also propose or request to have dedicated projects online meetings where you can interactively discuss and explore play with ideas this can also be done so we don't need to stay in this format this is a general presentation i can explain that later in detail so there's just an introduction every project uh can handle that questions on this project idea see somebody in the chat regif is hinting to information don't forget to add that in the meeting notes i lost track of the meeting notes here other questions don't be shy questions mark wanted to say something no no just i think actually if there are no questions i've certainly been pleased with the boldness and the creative creative genius applied by for instance vandit and several others who were attending with us today have submitted whole requests to the jankins.io documentation site for things that i thought were really quite advanced and and so well done that's great my apologies that they're not yet reviewed and finally merged vandit for instance picked up the upgrade guide which i thought was a major huge challenge and has started a very nice work on it so there are ways that you as google summer of code candidates can learn things about the sites and also help the project great well congratulations there well done okay we'll keep a couple of minutes at the end of this meeting for other questions let's move to the third project uh screenshot automation for jankins documentation i think this is one you've been pushing mark sure yeah so the idea with this one is that when we have jankins user interface improvements which happened quite regularly and we had multiple major releases last year with jankins user interface improvements those user user interface improvements are not reflected in the jankins documentation and so someone has to go through the jankins documentation and capture new screenshots now screenshots oddly enough are a very common thing in user interface test automation tools like selenium or cypress uh do navigate web pages and do perform screenshots of those of those things what this proposed was hey couldn't we take some form of description of the steps required to reach a particular ui put that into the documentation as a comment and then use those comments in that documentation to drive a tool that would capture the screenshots based on the latest jankins jankins release the idea is hey for the candidate who takes this project they're developing some very useful skills in web browser automation and web browser automation is a big deal in many locations uh the jankins project benefits by getting up-to-date screenshots when those screenshots are taken now for me go ahead john mark no no no i was going to wrap up but do you have something to add no so this is a useful project it would uh help improve the documentation and off top of that this is about learning skills uh that are useful in other open source project but also professional correct right you'll find you'll find many many companies that are choosing to use web browser automation as a way to test their web centered products that was a good sales pitch mark thank you thanks very much any questions about this project i think this one was clear like clear and easy to explain we can dig oh yeah how are you doing yes go ahead oh there are two people talking at the same time so let's okay i'm going on you geary yeah i'm going on i'm gonna have you go first shashank we'll go have you go second is that all right so geary go ahead yeah my name is geary and i am from india and my question is you could please tell me the current process for taking and updating screenshots in jankins documentation sure the the current process is we find the screenshots we tell someone please go recreate that in jankins and use a screenshot tool on your computer to take the screenshot and then submit it as a pull request to the to the documentation kevin martins had to do that he's our jankins documentation officer and he did it three or four months ago and it was it was a useful thing that he did but it was not a terribly thoughtful thing that he did right it wasn't filled with intellectual activity okay john mark said the word it was boring right and automating things that are boring is a good thing to automate so did that answer your question geary yes yeah i want to share an idea regarding the screenshot automation can i share that you're you're certainly welcome to um although i'm not sure this is the forum for ideas on implementation usually what you'd want to do is put those in your idea or discuss them in the chat channel okay so shashank i think you had a question so before we let geary continue shashank what was your question yeah good morning everyone i'm shashank so i have one question like what is the scope of this project like for example one can be just take the screenshot and save it to a folder like some resource slash image or or it can be like taking the screenshot and updating it in the resources also for example if we change the version of the jankins in the jankins dot io then image will automatically get fessed and it will show up in the website right this is my first question okay and so so good good good question so the jankins documentation site is intentionally managed as a static site because it's a static site that means we take the content from a repository build it and deploy it as a site so what we would want this thing to do is submit be be usable to submit ultimately pull requests to the jankins documentation that say here are the images that are being updated now now that's fairly advanced and this project would not necessarily need to be the thing that submits the pull requests but it would need to place the image files in the correct locations in the documentation set for any image that it updates so i see also a link with the documentation project the new version versioned documentation with entora certainly and absolutely i actually that's a very good point because screenshots are clearly versioned representations aren't they right i mean they are exactly versioned representations or something yeah very very good point thanks so shashank did that answer your question or did i just use lots of words and not actually answer your question well you answered my question thank you and the second question is the skill to study slash improvement it is written here image comparison can you please explain why this is quite like image compression can be so that we can render the webpage fast but no no image comparison here is i think that the purpose for calling image comparison here is not for speed of rendering but rather to decide if a change that has been generated is a relevant change or not so conceivably if a change was three pixels of color that changed and nothing else it may not be relevant and so an image comparison concept might be needed to say hey let's let's do something let's choose that this is a significant change or an insignificant change uh there's a there's a UI automation tool i think called zikuli that does something like this where what it does is it takes pictures of your entire screen and then tries to apply image comparison techniques to decide if the reference screen and the new copy are actually relevantly different so that's what i think it's trying to say when it's pointing to image comparison is that there could be some sophisticated techniques for comparing the two images and deciding this is a relevant update or no there's not enough change in this one to be relevant for to actually justify a pull request to to update the content did that address your question oh yeah and my last question is in this documentation you have mentioned for the gifs and videos like plenty we don't have them in our website right okay now i'm not sure i understood i think you i lost some some sound there breakup so you mentioned videos and this thing is not focusing on attempting to do any capture of videos it would these would be static screenshots could you restate your questions so i'm sure that i understood yes yes in the project details first point you can see that here it is written that may be extended to render a series of screenshots embedded as a gif or mb4 oh i see okay mb4 yeah okay good point yeah we'll see yeah and and that so for me this is this part of very brave extension that would be a very very brave extension because you're trying to say how do you decide how many what what the step should be in the the screenshot that is updated there's a stretch goal right very much a stretch goal okay but you could describe it and and say how you would handle it so what were what would be the the advantages of doing that you you need to sell the idea and you're selling yourself in a proposal okay we have four minutes for other questions on any project hello um honorable prattam prattam you can go ahead hello so like i want to ask in this project like i get the idea of the like web browser automation sorry prattam go ahead again please i didn't hear you hello like i want to ask the like the i have a query like in this particular project like i get the idea of the web browser automation because currently i am doing the automation in my internship so it's i know this thing and i my question is like where do i start so that i can prove you like i know this thing so i can do it so one way might be to to create outline what you think the human readable format should be and then show a little proof of concept that says hey this human readable format and whether that's capybara whether that's um cucumber whatever format you feel that is should be here's this basic format and here's how we would use it here's how a user would do it so what you're doing is then describing here's some of the concepts that might be involved in doing this okay and uh i want like there is a little query like i am not new to this and uh i joined the the last p week in the Jenkins so should i like okay focus on this to make lucky or like how to approach like this project or should i like okay contribute to like issues currently like issues like new issues in the Jenkins the main project you're going to need both so the the bigger challenge for me is assuring that that your project idea is solid because your project idea will be evaluated by the by the potential mentors and we will read your project idea you need to be sure that that is reviewed and discussed in the group that it's publicly visible etc all the good guidance that john mark has offered okay so like i have to be active on the both sides yeah yeah yes well so so absolutely you'll need to show skills in both areas your project idea will be the the most crucial but if you have not been active in other areas okay reviewers like me are unlikely to be persuaded that you have the skills you need okay okay thank you we have a question for mohammed wanted to get lost go ahead mohammed yeah yeah can you hear me now yes yes yes yes okay uh i didn't raise any pr on jenkin github so is it mandatory to be approved or i just raise one pr which help a mentor to see my foot so so is it mandatory no uh it certainly is not mandatory the the github the the google summer of code rules don't require any such thing is it very wise to show those of us who are evaluating your project idea that you are involved enough in the community to know how to submit a poll request to know how to respond to feedback to know how to get that poll request revised so that it finally is merged yes those are important skills because the project's success ultimately will depend in part on your ability to do those kinds of things john mark did i say it well enough yes very very wisely so it's not required but if you have that it will help for you to have a strong case so that the mentor will not have to spend time to explain and coach you on basic things and lose time uh on uh on that yes the for me the there is so much benefit to every one of you learning how the workflow operates to submit a poll request to receive feedback to respond to that feedback to get that poll request all the way to merged that is so important for you and will be so important for you in your career that it's worth doing that no matter what else okay we're at the top of the hour i'm sorry or people that might have still have questions don't hesitate to ask them in the regular channels the gitter gsoc sig channel and on community.jankins.io and we can see how to move forward we meet again on Tuesday to discuss other projects the agent reconnection and the gitlab improvements gitlab plugin improvements will be discussed on Tuesday and the rest of the projects will be discussed same day next week and i think we we covered most of the projects i think everybody some of you it has been very late uh in the time uh time of the day or very very early uh because they're on the west coast of the united states so thank you everybody to uh to have joined thank you for the questions and the energy uh that's behind that i'm looking forward uh for a great summer uh together thank you very much and see you online or uh here in this meeting later bye bye everybody bye thanks john mark thank you thank you thank you bye bye