 Welcome everyone. This is Mark Waite and it's the Jenkins Doc Special Interest Group meeting today. It's the 22nd of May. Glad to have everyone here. Let's review the agenda and then work through it. So we'll talk action items, then GitHub projects, milestones and issues. We've got data on contributors and contributions that I wanted to be sure we work through. And if you're here and interested, we could do a section on Google season of docs and timeline and project ideas. Okay, good. Well, then let's put that a little earlier so that we can be sure that you understand the things that are there. Good. All right. Oleg, any other topics that you feel that we need to get on to the agenda. No, nothing specific from me right now. Okay. All right, so then let's work through the action items. A doc sig summary. I'll write on that today. Submit it for review over the weekend in hopes that we can consider posting it next week as part of the hackfest blog posts that will be coming out. Oleg had run the palm meetup with James Nord. Thanks very much. The presentation has been recorded and is available on YouTube through that, that link. And then we had an item Oleg list the GitHub apps and plugins that use them. Are you comfortable with that one or Um, so it's still standing. I haven't touched it. Super. All right, thanks. Okay, then we've switched to using GitHub projects milestones and issues. We've got two GitHub projects now one is the user guide rework. And this is the board that it shows. Oleg anything you wanted to share here on the specifics and how this can help us. It's additional to GitHub issues for GitHub issues are helpful because they're easily discoverable by users, they can manage to write in the same repository as full request. And in general, they're much more convenient for users than Jenkins zero projects is just a representation basically a snapshot of the project. Why benefit from that everybody can go to this dashboard and see what's planned on what's left what's in progress and what needs to be used. So, yeah, that's the main benefit of this dashboard. Thank you and in addition to the user guide rework we've also got the administrator guide update project. Yeah, right. So, you know, one, ask to you mark. So when you create issues and pull requests, please add them to the project. Because otherwise, firstly, it would help contributors to understand the way it belongs user guides admin guides and secondly, it would still help us to further the progress. You bet. And so, so one of the things that I needed to clarify was that the content should in general that we're creating in GitHub issues here should generally assigned to one of those two projects. It's not, it's not it's rather atypical that we'll get something that's in an issue that's not either a user guide or an admin guide is that correct. There might be other issues, of course, but for documentation, almost everything now. So we have user guides, we have documentation guides, we have contributor guides. So this is semi official categorization right now, and also developer guides. There are four types of guides on the project. So whatever we keep page likely belongs to one of these four categories. We don't have special projects for developer guides right now. But so that that says that for instance, when I created this monitor and restart offline slaves from wiki just yesterday it should be assigned to the the admin guide. That way it's tracked as part of that. Thanks. Okay, so I can revisit those and be sure that they're assigned to projects as I've been working through these making progress on them. They'll they each one should go to one of those. I assume it would be also okay if we created created additional projects, not just for user guide and admin guide but for developer guide. If there's something that is developer centered. Yeah, if you plan to do the integration, it would be nice. Because, yeah, right now we have only user guide and administrator guide, for example, Jenkins project for more. So having something for for developer guide would be useful for contributor guidance. We don't need a project because that is all of the one Jira, which is mostly complete. Right. But yeah for developer guys, I think it would force having the project. Great. Okay, thank you. And then in terms of we also have we're also using a milestone in GitHub. With regard to the public roadmap. Oh, like is there anything here that I need to be aware of or that we as a group need to be aware of in terms of how to use this more effectively. Okay, so it's, this is this is another this is another another concept and now that we've enabled projects we could use. We can conceivably do a roadmap project instead of doing a road roadmap milestone. Exactly. So I just understand mostly because it was for my personal use. Right. Right now I think it could be just kind of. Great. Thank you. Thanks very much. Okay. In terms of our progress. We've got, we've, we've run a series of we ran a 90 day sample of the of the accesses to the wiki pages. And out of that came a list of 245 pages that had been accessed of those 74 have been triage. And either assigned to get hub issue or listed as no, no action to be taken, or we just need to redirect 171 of them still need to be triaged. So the I'm working through them steadily, and others are welcome to. There is actually a spreadsheet that I'm using to do that now I got tired of fighting with editing tables inside JIRA, and so that sheet is here. I'm going to link to that into the signals. Okay. So one question to you, we have a training session about that on Tuesday. Do you plan to invite contributors to contribute to this charge there. I was, I was assuming that that an inexperienced contributor may have difficulty helping with the triage I'm open to guidance on it. But that, for instance, deciding where to put something is typically one of those which we, you may need some past experience, but I'm open to suggestions. What do you think should we invite contributors to assist it is the pages open for comment. So I could make it so that they could comment to the sheet. I did, but the disclaimer to that it's advanced topic. Oh, okay. That's, that's good. All right. Okay, so I'm currently working on your first projects listing update. So I will just edit there. Great. That would be wonderful. Thank you. Anything else on GitHub and how we're using GitHub to accelerate our documentation work. So the next topic. This one I think is for for your benefit and for others who may be viewing the recording. So the Jenkins project has been accepted as a Google season of docs project. And Oleg is one of our work admins. I'm one of the mentors. This is our, our chance to review the timeline. Right now we are in the technical writer expert exploration phase in that phase writers become familiar with the project and come to understand what the project offers and how they can contribute. That will end in about two weeks on June 8. And then there's a month that technical writers are allowed to submit their applications proposing the work that they would do during the during the period of Google season of docs. And those applications are described here through this link from the Google season of docs page. It talks in detail about personal information your experience and the crucial thing, the project proposal. So this is what has to be done and submitted to Google by the due date, it should, we found that it's very good for these things to be reviewed first by project members in draft form so by Jenkins project members in draft form before they are ever submitted to Google. Okay, in your, in your experience with Google summer of code are there things that you would guide us on in terms of what makes an effective project proposal and what sorts of things those writing the proposal should do. So Google season of docs is slightly different from JSOC, but common expectations are basically the same. So we expect consistent proposal, which would be explicit in terms of deliverables. So basically items you would like to improve. Also, this proposal has to be feasible. So for example, if you say that I'm going to write Jenkins user documentation completely. It's not feasible proposal. It might be a valiant goal, but it's not possible to do you think Google season of docs. But for example, focusing on a particular area like let's say Kubernetes doc, maybe just refining user guidelines or installation guidelines. This would be a scope which is feasible. Also, for Google season of docs it's important to take a project which would be available to the community, which would be available to contributors and to Jenkins users. Yeah, I think that's it. So obviously if you do any contributions to the Jenkins project, of course, will be much appreciated and usually contributions help potential mentors to refine their proposals and come up with better plan with better application. So what we see historically, the most of our contributors we accept Google season of docs do some contributions before the occasion. It's not mandatory, but in practice it helps a lot. Okay, thanks. So are there any specific questions that you had we have the advantage that with with just the three of us here it's a perfect time if you've got specific questions you'd like to ask. Regarding the question, like I was thinking like when I hadn't participated in the competition. So I was like just thinking how to figure out the proposal like what is that any draft format in which the proposal should be permitted or are there any sort of draft in which I should form a proposal, like what are the things that should be mentioned in the proposal, like some questions, like why I'm interested in that project, or is it completely up to me how I format the proposal, what all things I must add in it. So I briefly listed what would be needed in the previous question. So if you're interested, you can refer to guidance for Google or somewhere of course which are more documented on the Jenkins side. But yeah, the most critical thing is clear a list of deliverables. So basically, let's place a list of what you want to do. Preferably with some planning, preferably with some details, but yeah this is a key part. Okay, thanks. Yeah, and the document here on the season of Doc site gives you the specifics of what what they expect will be included. And then if you're looking for ideas, or what what things might you include in the proposal. The, the Google season of docs page on Jenkins that IO includes a number of suggestions of possible project ideas. So that let's see I'll include the link to that project ideas here later. Actually, let's just do it now so Jenkins IO, the docs community season of docs here. And this page gives us more info, including the project ideas. Let me just embed that into our meeting notes. Thank you. Did you have other questions. Yeah, no other questions. All right. Okay, so then in the past I've gathered data on contributors and contributions. We've, we've got 86 open GitHub issues now 29 have been closed that that's a steady improvement. We expect the number of open issues to increase significantly as we work through the triage process. And we're very grateful for people are contributing things to close it. In terms of the graphs, this time from pull request initial submission to engagement from someone who is not the author is looking pretty good. And it shows that for the last month or more time to mean median time to engagement has stayed at or below four hours. So that's really encouraging, particularly given that we have a 24 hour day and and so we've got people helping regularly. So there's a concern here in the time from PR open to merge that we've over the course of the last month shown a steady increase in the time it takes for us to merge something. So that's one where I've got to do more work on reviewing, we need we need to expand I think the, the reviewer team so that we can get more and encourage those who've recently joined it to submit their reviews. And there's a number of folks who joined the reviewers, but haven't been submitting reviews recently. Yes, so in my case I just have no band while because you are you're exact first and other things. So, all my time. I cannot contribute on a regular basis of basically on daily basis to reviews. But yeah, what I would like to say that even this recent decrease we're still in a pretty good range. Good, very good. Yes. It would be nice if you did get a bit more time. Well, and it's one that that same same problem for all of us I think this is one where as we encourage more contributors, we may be able to do it we had added several people to to invited them to contribute reviews and I think that's a good way to get more help there. I'll be working that. I just think, think about people. So, whom we recently slated and slated to Google some of the project. So, yeah, I would say that you shouldn't expect too much went right from human to focus. Who else. I think we added Vlad. Regular review school requests are good. Okay. Of course. So team team, yeah, team was also busy with prep work and we have system read permissions have allowed which also requires time plus Jenkins core. Because team is doing a few chunk of work related to Jenkins core maintenance at the moment. Well, I think we should encourage contributors to do more reviews but at the same time, we're still in a pretty good range. Excellent. I wouldn't say that it's immediate concern or red flag is to the majority of requests within two days or so. Yes, and that that is certainly true right we I mean, the 85th percentile emerged within four days. So yes, absolutely. Okay, and in terms of contributions from the last month we've merged 120 pull request that's a significant increase from previous months. And the number of issues with our switch to GitHub issues has nicely increased. We do have 22 open pull requests currently. And then that, I think concludes the pieces that I was worried about for this meeting Oleg are there other things that you think we need to review here. Yeah, we could quickly touch a topic about automatically compressing images. So, yes, I could just show what I'm going to do with that. And let's let me stop sharing and if you want to show us that automatic image compression is an interesting topic. Okay, so just a second, you need to make me a host. I've got a grant share. They've taken away my share. Allow everybody to share by default just a minute. So advanced sharing happens. Everyone can share you should have permission now. I think it really migrate to the Jenkins CDF account because today we have everything configured. Okay, do you see my screen? Do, yes. Okay. So one of the issues we have is Jenkins at the moment that we store images in the main repository. We wouldn't call it a good practice or starters because this repository is extremely big at the moment. And by contributing new content with images, we actually make it bigger every time. And while we have opportunity to change it in principle by moving to another repository or maybe not even to repository because you really really need to version images. Well, versioning them in Git basically doesn't give you any significant advantage. So what you have now that extremely big depository, for example, there is a new pull request for adding missing closers. And basically this is from where my actual work started because this pull request also adds a bunch of new images. And there were a lot of concerns about your much another 20 images or so when these images are not optimized and hence the size increases. And one of the ways to do that is to actually ask contributors to optimize them. But it causes firstly an issue for contributors because they need to figure out how to do it properly in this lawless completion. It's not always easy. At the same time, they spend time on that. And as we still have no team to say what they do compressed and all. Unless we check them out and verify. So goodness is that there are tools which allow doing automation around it. And for example, there are GitHub actions and GitHub applications which can modify images right inside submitted. So how it would like. Yeah, I'll just open my own version of this pull request. So here if you go, you have metablogers plus GitHub actions, a compression test. So basically it's the same pull request. But in this repository, I also have a board configured which automatically processed images in this pull request and contrast them. Well, one thing which was mentioned that it actually compressed all images, not only images submitted in this request because yeah, this is how this bot works. So we doesn't support SVG at the moment, only PNG and JPEG. Well, I think SVG is small amount of programming for maintenance of this board. But yeah, what was mentioned here that. Okay, so in the normal. So you can see that compression reduced images by 26% or by 20 megabytes. So in our repository, we have around 80 megabytes of images already. And every time you modify them, actually you just increase. So for example, if I mentioned this pull request, it wants to use the repository by 20 megabytes, actually it will increase it to buy 16 megabytes by 15. So that's the main problem with our architectural decision with the current website layout and structure. But yeah, so I think we have to deal with that for a while. So what is my plan here that I will create a blood list which basically just includes all previous images. So that we do not archive, we don't compress what is already in the repository. But for the rest we enforce such automatic compression. So every time somebody sends a pull request, the image will be automatically compressed, unless it's not already compressed. I always downside about that, but after that, you will have to pull the branch because this bot commits directly to the development bench. Yeah, this is how all bots work. But I think it will be still convenient to users because, for example, here, we can just squash measure this pull request. And after that, there will be no overhead by compressed images. So the technique that the bot is using actually is to, it optimizes the image and adds a new commit. So we must be sure that we squash merge, otherwise we get the unoptimized and the optimized. Okay. And is there a way that the bot can automatically label it for us to remind us to squash merge or there isn't. Yeah, so technically, I could add another bot, which basically changes the commit history and it's, if it sees a message like that, it automatically adds a squash merge label. But yeah, it needs additional automation. I can do it. Yeah, just knowing that knowing that this bot is a possibility. Now, have, has there been any consideration of rewriting the history and admitting that we're going to change history and replace the images in history. Or is that a force push is just given the number of forks of this thing terrible to consider. Okay, to consider that, assuming that we do a sexual change. So for example, if we move all images to another kind of storage, I see. Well, I'm not sure what would be the storage. It can be a service because right now we have CDN. So these images are served from CDN anyway. It would be just a separate repository. It might be get a web first or whatever. So it's implementation detail. If you move images outside of this repository, it will, it will be technically feasible to do force push. But yeah, what force push means that basically all four requests which are stated, they will become a mess. Right. It's, and the get community guides against force push so understood it sounds like it's not a not a viable thing here. Okay, good. One of the ways to do that is to actually create a new repository to archive the existing one but again, it will lead to the loss of contribution history, etc. So it's pick your poison. The problem that right now if any contributor wants to work on this repository, then this contributor needs to check out around 100 megabytes, which doesn't seem to be a tremendous size because here, for example, if you want to develop the size you will like me need to check out a few gigabytes from Docker because I'll make files based on Docker. But they're still formally make quite big repository. So, now Daniel Beck had asked a question about some of the images where he felt like we could dramatic could have dramatically sized them down earlier any guidance there. I think his comment was something about. Hey, we're presenting a 700 pixel wide image but it is the source, the source images 10 times that size or something like that. It's a, it's a case. It's not something the existing bots can do for you. At least, I haven't seen a bot which was automatically resized images. I can assume that they exist. For us, there are some bleeding examples, if you wish, just a second. So, for example, at some point we managed a blog post about five superpowers. You may remember that. And if you go here, here's the images and basically it's a case Daniel was referring to because this 69% compression is a compression for really high resolution image. And we just show an icon which could be just pixels. Okay, so right now if you open this page, you download quite a number of megabytes just to see if your icons. Got it. Okay, thank you. So, so that would be a that is that is a viable and separate thing that we that we could do now it would for that particular page it would benefit that page if we optimize the image at the cost of adding a new copy of these the reduce size images to replace those bloated images that are there. Yeah. Okay. So, we could do trust exchanges, but there should be strong justification for now I my suggestion is to just ignore everything here. I think it's only for new images. Because, yeah, some images, they can easily be filtered out some images cannot be. But it's still a small amount of programming to have everything to the north. Great. All right, well thank you all like that. So this will mean that when when a contributor after this this pull request after this tooling is available, a contributor can submit images, not having had to worry about them being optimized images. It will optimize the images. I assume they should choose an image size that's reasonable. So, keep it about the size that that they need for their page. So, yeah, how it's implemented right now. So basically, I'm using existing clear graph board. And it does lossless compression for all of them. Yeah, if I go after 80%. Yeah, probably we could use the image sizes twice more. But I don't know. So I just did lossless. And so 80% is what's being done by default and 80% is default for many tools. And G crush and other things. Thank you. Yeah, my plan is to get it over the line. Preferably before the hug fest. Yeah, no strong no commitment. Excellent. Thank you. I think that covered all the topics that we had today. Any other topics that need to be discussed. Alright, thanks everybody. We'll meet again in a month. We've got the hack fest that starts next week. Thank you for your presentation on it. The intro is on Monday. The docs presentation is on Tuesday. Looking forward to both. Thanks.