 to Google season of docs office hours. This is 25th of March and great to be here. Let's see. So I had one, two or three topics proposed for the agenda. Declare office hours are the docs sig meeting. So that's a topic for this. So first was talk about the contributon status to be sure that we're okay there. Then talk about office docs office hours be becoming the official meetings of the docs special interest group. And I'll give a brief overview of why that and season of docs. I'd like to do a final review of the project plan and the organization proposal. Let's see. Let's call it what it is. It's the organization proposal. And once we've got, and then I will submit that later to do so, yeah, pending pull requests. That's a good one to discuss the Kubernetes change proposed to publish as draft as work in progress. So that's one from Oleg. We should talk about it here. Xenopo you're available. Any other topics you want to put on the list Xenopo? So what I wanted to talk about still falls on that contributon. So I think it's fine. Maybe when we start discussing. Okay, great. Let's start with that one then. Okay. So what was the topic you most wanted to cover there? So right now we wrapped up applications last week Friday and we had over 180 applications from ladies who wanted to contribute to open source. And we kind of don't have enough open source projects currently, like we just have three open source projects interested Jenkins, Deploy Hub and BF5. So we were wondering if Jenkins could take in more mentees for that, at least we can be able to take in more applicants. Cause right now we can only take in 12. Considering the numbers, the open source of musicians submitted. And that's like, okay, no, now it's now 14 cause they are five inquisitors. We can only take in 14 out of 182 applications which is quite low. So we were wondering if Jenkins could probably take in more participants. I remember you mentioning something about the project idea of replacing old terminologies in documentation and things like that. I don't know if we have other ideas that we could, that's this participants could work on. We would really, really appreciate. Then also for the pipeline examples, if we could take in more participants, since they're going to be working on the same project. Very good. Okay, so let's, how about we take those in inverse order? Because I think we can take more people, more participants on the pipeline examples topic, especially if they're willing to sort of work together as they bump into challenges, contact each other. And yeah, so I think that is doable. I would guess we can't take much more than seven or eight. So we currently plan for three. Yeah. Could increase that one to increase to, let's say, well, let's see, what do you think? What if we went to eight and said eight or even nine and said, okay, we're going to allow that, we'll find a way to, because the project idea has huge potential in terms of what people can do with it and the number of places that need changes. So if I remember correctly, the list of top 10 plugins, let's see, where is my page that takes us to the sheet, the pivot table? Here we go, this one. So let's, this is, yeah, okay, good. We look at the pivot table and here, down at the, whoops, down at the bottom of it, there were 10 plugins. The top 10 still had lots of feedback on them, but then we've still got plugins with multiple points of feedback, 25 or 30 of them. So it doesn't seem like, it seems like, yes, this is a reasonable way to approach it and there's lots of work to be done here. So if you think you've got contributors willing and they wouldn't mind helping on this sort of larger effort to make this better, I would say, let me propose it at least to others, suggesting, hey, we're going to attempt to accept nine and try our best to mentor those nine. Okay, so three, okay. And actually now why nine, why not make it just 10, make it a nice, nice round number? Yeah, so let me, let me propose it to the community, to others and I will attempt to enlist more mentors. Okay. Cause that one is, this one has the benefit that it will get them into the, into plugins, compiling Java code, experience with Jenkins. For me, this one was a really good choice for your participants because they will have such a good experience, not just contributing to Jenkins, but also learning things for themselves. Okay, okay. So, okay, one, two, three, four, five. So another thing I wanted to ask is, for the Java requirements, it's compulsory that the person has to have like some experience using Java, right? Not, I wouldn't even call it, let's, the intent really is just that they have, they have some experience compiling code with Java or otherwise and are willing to learn. Because I don't think you need particular Java skills to do these tasks. Many of them are more about explore, ah, and then during, during development, they will have to run the Java compiler and they'll run it with Maven following the instructions here. And so I don't, I don't think you should set a precondition, good if they've got Java, if they don't have Java, but they have some experience compiling something else, either using Yarn to do, to do JavaScript-based compile or make or, you know, those kind of things. The, the, there's nothing special about Java here in that sense. Okay, cause most of the applicants kind of like have more of JavaScript experience front end and things like that. We don't have as much Java applicants, though we have some, but I'm not sure if after the interview, we're going to be able to get up to nine or 10 participants that have experience with Java itself, but we have applicants with other programming languages, majorly Java scripts. Okay, so, so, and so now that I guess the question to you is are Java skills useful in your area? I assume that the reason they have JavaScript skills is their employer needed them to have JavaScript skills. If Java is not terribly useful, you may want to prefer to put them somewhere else, but, but I guess that's your, your call as an organization. Okay, if the thing is most of them are willing to learn, most of them are willing to learn. So, but another thing is during the interview, we just ensure to ask them questions around interest in learning or using new tools, you know, things they are not really conversant with and we're sure to make more preference for those who seem really interested and enthusiastic. Great, okay. Well, and that, that for me, that for me feels like the right question. That's if, if, if I think Java skills are quite valuable, but given that most of your people's experiences with JavaScript, that may hint that they're not as valuable as I think they are. And so you know your market there for development talent much better than I do. Okay. All right, that's fine then, thank you. Okay. So, so that one was, that one was a, and for me, that's a fairly easy one. The next one, terminology replacement would love to have it. It, I don't have an introduction. It needs a better task, better task breakdown. It needs a real task breakdown, right? And, and some good sample codes, some good, yeah. So, but that one is very much something that we could, we could take on additional people if you've got people who could assist. There the skills are typically it's Java, Java compilation interacting with Jenkins to see that their change made it and then submitting pull requests. And the bigger challenge here is that there are times when they would need some, or they would need an introduction to the concepts and the places where they can make changes and where they cannot. Okay, okay. So, at the end of the day, I think the maximum we are going to be able to take in for Jenkins is still going to be around nine because we are looking at 20 because you know, SC is going to have to pay each of them. So, considering the funding that we have done, we're looking at probably a total of 20 mentees. So, if Jenkins is able to take nine, I think that really solves our problem. So, it's now left for Jenkins to decide if you want all of them to work on the pipeline examples or if you want some of them to work on technology, replacements or that's to work on pipeline examples. Good, good. Okay, so let me take that. That's great guidance. So, she called Africa may be able to provide nine mentees. Okay, great. And so, Jenkins recommend target projects and that's a good excuse for me to have a conversation with people. I know I have a number of people who say, we'd like to do terminology replacement. I intentionally chose this one because of what I thought was a good mix between the development experience but this terminology replacement is work we very much want to do. So, this will be a good conversation for me to have with some people in Jenkins project. Thank you. All right, thank you, Mark. Okay, well, so I did get two additional volunteers in the Jenkins project who've agreed that they're ready to assist when requested. And one of those two may be able to assist with what I'm calling the start of day time if we need one with start of day. So, our intent was when you tell us who the participants are, we'll ask them to help find what would be a time that we could meet with them to do a, to once a week to have good mentoring sessions. And we've got two teams available. So, one could meet early day before working day or early start of working day in Africa. The other could meet after working day. And so, the idea was when you've got the participants assigned, we will find times that work for everybody to meet together. Aha, this just reminded me of something else I wanted to mention, I forgot. So, wanted to have like an onboarding call, probably next week, Wednesday, or Thursday is first of April. So, I don't know if we're going to have it Wednesday or Thursday, first of April to introduce the selected participants to Jenkins, that's the mentors. So, we like a suitable time for you. So, we can share with the selected participants at the end of the day. Because right now we are already in the process of already scheduling interviews. So, after the interviews, the next thing will be to select participants that will be participating in the booths come and introduce them to the mentors. So, that brings me to the question I want to ask, what time will be convenient for Jenkins to have the onboarding call on Wednesday or Thursday? So, any time after the end of your working day there would be fine. Our Kristen Wettstone and I are easily reachable at this time when this meeting happens. And the other mentors I think are also reachable, even the ones that are in Europe. And Meg McRoberts, we can ask her to get up early that day and if she's not able to attend that's still okay, we can introduce her separately. Okay. So, could you share, I don't know when I'm sending the email, I don't know if you could share the contact details for all the mentors. So, I could include everyone in the email I'm going to be sending out to the mentors and also the invites for the onboarding call. I will do that, you bet. Thank you. So, let's just make it that way, Marks. Send email addresses to Zenon. Great, you bet. Excellent, okay. And... So, okay, so I'll go ahead. You've got the Zoom setup that you need or other form to do the onboarding call, right? So, you've got that covered or do you need... Yeah, I think I've got that covered. Okay, great. Yeah. So, I think why I brought that up was because I think the onboarding call would be a good avenue to discuss meeting times and I agree on meeting times with the mentees and things like that. Very good, yes. Well, and if we're using a Zoom call I wonder if we ought to use a breakout, a series of breakout rooms to... Is this just for one project for Jenkins or are you going to do all participants? And if all, then maybe we should consider breakout rooms. Oh, it's just for Jenkins, okay, all right. Yes, we're going to schedule separate times for different organizations. Okay, great. All right, so during the onboarding call. Great, we will do that. Anything else on the contributon? No, that's it for me. Okay. All right, so the next one is just a piece of sort of business for me. It is that I have docs, the doc sign meetings happen once a month. However, no one but Mark attends. And for me, that's no harm because doc's office hours meets twice a week and people attend every session. Wow. And people attend every time. So my proposal is let's just declare that office hours are the meeting of the doc sig. So this is a meeting of the doc sig. That makes sense. And I'll just update the, so long as you don't object, I'll just update the pages on Jenkins.io that declare that this is how we're doing it. And that way we're not wasting time and I can cancel tomorrow's meeting because we've got lots of good progress in the doc's special interest group without having to do a separate meeting. And then the one thing that I have to do is Mark periodically collect and report the metrics that are in the doc sig, in the doc sig meeting. And that's just a, that's a good healthy thing for me to do anyway as the doc's officer. All right. So you're okay with that? You don't mind us borrowing and defining this as a doc sig meeting. Great, thank you. Okay. Yeah. So next topic was, I wanted one final review of the Google season of docs proposal that we're doing for 2021. I've reviewed it with Oleg. I've reviewed it in other places. Let's see if it's now up to date. Come on. Yeah. So I wanted to ask a question about the Google season of dogs. I saw Oleg's mail to the mailing list about mentors and org admins. So I wanted to ask if there was like some sort of requirements or something like that to be a mentor for the season of dogs. There is not. We, in fact, we've had, we're looking, I'm looking forward this year to having mentors who were previous, so mentors in Google summer of code who last year were students in Google summer of code. So no requirement at all other than willing to be a mentor. So for instance, if you are interested in being a mentor this year, would love to have you. Okay, then I'm interested. Great. Excellent. Thank you. So I will, I will include you as a candidate mentor. Right now we've got, and I will put your name right into the application because we've, I submit the application in a few hours. So very soon. So let me make it. So Xenov willing to be a mentor for Google season of dogs. Good. Very good. Excellent. That actually makes a nice incentive for why they should choose us because not only did we do the project last year, but we're having the contributor who did last year's help us with this year's. That's a great story. Thank you. All right. So in terms of this project, the idea here is that we're going to continue the work you did last year and broaden it and deepen it. So Jenkins on Kubernetes continues the theme of this. And what they asked this year was, hey, what are the problems you have? And my description was, hey, deploying Jenkins on Kubernetes uses lots of different components and any one of them could be cause a problem or get in your way. So Jenkins on Kubernetes is complicated and needs better documentation about all sorts of aspects. You did the installation part. You've done some initial work on sort of scaling topics. Now there are more levels that we need to address. And we want to, as our goal have users be able to confidently deploy Jenkins on Kubernetes. So the idea was let's, and this is a different project this year. It's now six months, but it'll be six months part time. And in that six months part time, what I've proposed is several phases. One is a preparation phase where get the writer confident and comfortable with Kubernetes. And that's something we didn't do with you. And I think it might have helped you if we'd admitted we were gonna spend some time having you be comfortable with Kubernetes. Then after that, oh, go ahead. No, I didn't continue. This makes a lot of sense. Okay, well, one of the powerful things about asking your review is I would love to have additional insights from you or say, oh no, that wouldn't have had, that won't help or this might help. So Docker images is a place we know we have a need. People are continuing to make mistakes in how they define their Docker images. And so we need documentation that guides them to choose well how they create the Docker images that they'll use in Kubernetes. And these two topics are specific to that. How do you do a good Docker image for use in Kubernetes? Then we've got lots of people who tend to make mistakes in terms of defining the system administration level things in their Jenkins install. What's the authentication scheme? Which components need this configuration? Which ones need this other configuration? How do you get secrets into it? Those kinds of things come in this phase. And then dealing with agents is another complication that people need to be aware, oh, this is how you do Kubernetes based agents. This is how you do static agents and yet you still are running in a Kubernetes cluster. Okay. And then the last phase was a solution page. And I've got actually two more phases after that but Oleg correctly guided and said, hey, more than four phases is probably too much to fit into even a six month project. Your comments, what do you think? Which, what's missing here? Well, for now, I think this is good but I still have to just maybe look at it later on to see but for now I think this is fine. Then also I think Oleg's idea of having more than four phases is also correct considering you might have some blockers or issues along the way and you wouldn't want to overwhelm whoever is writing but if the person is able to finish the four phases within the six months and there's still time, it's okay to add more content. But for now and I think this is fine. You could just probably have it like maybe future work or something. So in case if you're able to finish everything then you could start working on that. And if not, it could be part of the person's project report or something that this is what I was able to do and this is where you can continue from. Great. And I've got, I've actually placed the, well, if we look at the page, I've placed the other phases in as comments. So the phases are hiding inside this document. Oh, okay. So if we, if it were, if a miracle happens and the project goes faster than expected then that's great. We have other things to consider. My assumption is by the time we get to this phase four we will know so much more about what we should, what's missing that we'll probably reshape it entirely by that point and say, oh, it should be this. And it felt that way with your work on the installing, right? Is there were things that we thought we knew initially and we were just wrong. We didn't know that. It was, oh, we needed to do this and we needed to do this and we had missed those completely. Exactly. Yeah. Like the skeleton working on the skeleton. I had already started working on the install though. Before Oleg mentioned, wouldn't it be great to have like a skeleton of what you want to work on first? There's something like this that you just did now before starting the writing process. So I think that process would actually help this to go much smoother. Great. Okay. So you're okay with that concept. Then the next was, let's see. So measuring project success was, I think we can look at the Google page results. So the Google tracked clicks through on our pages to see how we're doing on references to the Kubernetes specific pages. Also, I thought, hey, we would look for positive feedback in our feedback spreadsheet, right? This sheet that collects comments from people that they give to us. And we would look at, hey, our issues, we're not getting a bunch of new issues on Kubernetes documentation. I'm open to other ideas of how to measure project success. That's the success of a documentation project is hard for me to see how we measure it. So that's a big question. So would whoever is working on this project have to complete all the writing pieces? Like is it compulsory? It is not. So I would assume if we get, I will feel great. If we get through phases one and two, that will already be a dramatic improvement. So for me, I am not envisioning that this is, we must complete all four phases. I would love to complete all four phases. If we got through phases one and two, I will be delighted. If we get through phases one, two and three, we will have completed an amazing outcome. So for me, I would love to have all four phases and I think it's feasible, but we may learn that Docker images is so important and so massive that we have to spend two months on it. And that only then leaves us four months for the remaining three topics. So did that answer your question or was I answering the wrong question? No, you weren't. So because I was thinking like, definitely in measuring project success, we would need to kind of like include the number of writing faces that you should at least be able to complete within six months that is very, very reasonable. Say with any or whatever issue that might come up or any obstacles, at least we should be able to complete say probably phases one and two. Good insight. Okay, very good. Let me make a note of that. Clarify in the application that project success needs to complete prep, phase one, phase two needs minimum to complete, right? Because if we spent, if we spent Google's funds and only got through phase one, I would not feel good about it. That just for me, that would not be success. I think you've got a good point. I was thinking more of external measurements, but I think you're right that we want, if we can't say, yes, we did this and we did this, then I'm not ready to say that it was a success. Okay, so... Oh, hi, Kristen. Didn't know you were on the call. Oh, it's all good. Hey, I'm here. Hello, Kristen. So sorry that we were just blissfully going on in our conversation and ignoring you. That was not intentional. No, it's all good, don't worry. I had to join a little late because of a work call. Yeah, thanks for joining. So don't know when you joined, Kristen. We're reviewing the Google season of docs. I would like to go through some of the other materials since you're here and be sure that you're okay with decisions that Xenob and I came to. Sure. Okay, cool. No, yeah, that makes sense. I'm sorry, I just wanted to comment. It's like, yeah, I agree with the, we need to accomplish at least the two phases for it to be successful. Oh, good. Okay, all right, so you... It's really the configuration I co-stuff is really to get that documentation updated. Good, all right. Okay, very good. Thank you. So Xenob and I had a conversation about Chicot Africa contributon and they've got over a hundred applicants that want to contribute. And they're going to, they've got funding to support. It looks like up to 20. That's great, 20, but projects, they need more open source places where people can work and they've said, hey, they could take up to nine. Okay. Give up to nine to the Jenkins project. And my initial proposal was, let's put all nine of those people as many of up to that nine as they can on the pipeline examples idea because of the number of different plugins that will all benefit from these pipeline examples. So it's actually independent work that each of the participants can do in their own pipeline, own plugin. We just have to split them out and be sure that they understand, okay, you're working on this one, you're working on this one. Sure. And there's probably some other, if that, at that point too, it might be worth it to just have someone go through or maybe like two people maybe go through like the pipeline cookbook and make sure that is, you know, they be making sure that that is up to date and that has good examples and stuff too. Cause I feel like I was recently going through that and I saw a couple of places where maybe there's only like the declarative example and not a scripted example. One thing that I personally ran into with work recently and I never really can really found a good answer for it and it'd be good place to investigate is can I use a library from another library? Maybe some examples of that, I'll do some exploration and just kind of doing some tightening best recommend or best practice stuff too. So not only updating the actual steps but just in general covering our the documentation for the pipeline. Good, very good. Very, very good. Okay, excellent. So in terms of the number, are you okay with us adding additional participants on this same project? So thinking that I think I've found, Oleg has agreed that he's willing to help as needed and Angelique Yard has also offered her help. She's not sure she can be available as often as needed but she's offered some help and I think we could recruit additional to support us. So my sense was taking more people on the same project where they can help each other when the mentors aren't available, maybe a real positive. Okay, sure, that sounds good. All right, great. Now the other that Xenobit suggests is if we run out of or if we need, we could ask them also to help with the terminology replacement project. That's more about documentation whereas this pipeline examples exercise, they're really gonna be in their compiling code, they'll be modifying, changing, admittedly the changes they're making are in HTML files but still it's about a code experience whereas this one is more about a documentation experience. Right. Okay, good. So I think what I'm hearing then, Kristen, you're okay with us going with increase our maximum number up to nine and that's great, I'll keep looking for more mentors. Sure, yeah, as long as, cause there is so much stuff out there that people can divide the work. I think that doesn't hurt. So. Well, and that was the, that's the fun part for me hiding in, where is it in this one, right? Here's my pivot table of which plugins have feedback on their OG. That wasn't that helpful. And 30 or more plugins have multiple feedback items saying, hey, I'd like more documentation on this thing. Right. And yeah, it almost feels like some of the best documentation and stuff is be actually using the snippet generator. So it's like, if there's a way that we could kind of try to make this closer or make more sense, like with the actual examples of what it would look like, I think that would like very much help this project. So. Right. Well, and we've actually got a step in this, in this tasks document that talks about encouraging them to use the snippet generator, writing into every one of these plugin documents. You should use the snippet generator. And here's what I'm doing. Because really some of the feedback hints that people just don't realize that the snippet generator is even there. Right. So just reminding them, use the snippet generator. And here's how you do it. Yeah, very good. All right. So that was that one. Then, oh, the other change was, I'm proposing that we're going to declare that this meeting and the earlier meeting on Mondays are officially Dock SIG meetings rather than just office hours. Because we get much better participation here than we do at the Dock SIG meetings. So I'm gonna cancel the Dock SIG meetings that happen once a week or once a month. And instead, these twice a week meetings are gonna be it. And no objections from you, I hope. No, that makes a lot more sense, especially with people coming. Is there anything that specifically goes that you go over in the Dock SIG that... Just one item, and I've put it here, and that is reporting metrics. Okay. I report how well we're doing it at handling pull requests, for instance. And how quickly do we resolve them and how many contributors, those kind of things. And those are good things to gather, but I could report those here in three minutes, just as readily as do it in the other meeting. Okay. All right. So I think, thanks, Zinab, for your patience. Thanks for your insights on Google Season of Docks. One last topic, pending pull requests. So Oleg had asked, hey, should we merge the pull request as a, here, let's go read his phrasing. I like it. Should we merge it as a work in progress? Just admit that Mark's not been very successful in making this happen. So would it make sense to merge this document as a work in, with a work in progress disclaimer? Zinab, do you object? No, I don't. Okay, great. Then I will go ahead with that as well. Sorry that I've been such a block on this one. Thanks, Kristen, for your patience and being willing to offer. Great. Yeah, sure. And then, you know, maybe someone, this is a good, another good example. It says work in progress is a really easy way that we can highlight. Like, help make suggestions to this page. I know that there's that option, but it's maybe, I don't know if the disclaimer has a extra highlight for a, if you have any extra questions or suggestions. Like, I don't know if that would, if there's, if the disclaimer would have a link to that or it would be easy to highlight that in this part. That's an interesting idea. Should we include and improve this page link inside every work in progress indicator? Right, like a, I don't know. Yeah, so just like, hey, please help. Or if like, or if, hey, like, we've done this piece of work. Like, do you have any other suggestions for like direction we are going? Right. Because it's a work in progress. Please say, feel free to say like, this is, this is helpful. Or I'm, I'm really interested in seeing more of this. Can you, you know, add some extra details here? And that would help us be able to maybe drive the direction of that page a little bit easier too. Excellent. I like that. I think that's ingenious. I don't know why I didn't think of that. Very good. Thank you. All right. I think that covered the topics. Any other topics for today? None for me. All right. Xenob, thank you very much. And thanks again for presenting yesterday. We'll talk again in a week. Thank you. Thank you. Awesome. Talk to you later. Thank you. Bye. Bye.