 Welcome to Google, or Google Jenkins documentation office hours. It's the 21st of January, 2021. Thanks for being here. Let's, let's go ahead and talk to the topics. So I wanted to solicit comments on a proposal I just created for a Jenkins contributor summit. And so that was when I would love to invite Kristen, you and Zina both to comment on it to give me insights to suggest ideas, etc. Then I had pull request progress still a point for us to discuss Jenkins and Google summer of code and the Jenkins wiki plan we're all topics on my list. Zina, what would you like to put on the list. Jenkins on AWS. Okay. All right, so let's put that one at the top of the PR list. So Jenkins on AWS. Okay, and let me go grab that one. Sorry, I should have already included that in the PR status check. I thought we are oh no we have. Oh, I'm so sorry Zina. That's been approved for two weeks by Markey and I have not done the review and merge. So yes, let's get that one PR 4055 Jenkins on AWS reviewed and approved by Markey. Any other topics you'd like to put on the agenda. Next steps, what content we like to work on next for Jenkins. Great. Okay. All right. Okay. Kristen, any particular topics you'd like to add to the agenda. I thought I could think of but seeing the next steps for other documentation stuff would be really interesting. Good. Good. I don't know what they would be right now. Great. Okay, well, and maybe, maybe what I could do is I would propose under next steps let's hide Jenkins wiki plan as a part of that because I think that's a good candidate for a next step and others might be Kubernetes, Kubernetes improvements, including things like. I'm sorry say that again Zina. Kubernetes solution speak. Oh yes, yes, yes. Kubernetes general docs. Very good yes the Kubernetes solution page which we don't have one at all right now. And solutions page very good. Okay. Excellent. All right. Any other topics before we start working through the agenda. Okay. All right, so as a, as a brief on the first one and I promise not to spend much the I've created a proposal for an online contributor summit. The summit is an event that we've held once a year to encourage people to contribute to Jenkins to meet together to talk about what Jenkins should be doing in the coming year. We used to do it regularly at Fosdom and open source conference in Belgium, but that conference will be all online this year. So instead we're going to do this as an online event. The idea is we'll take three days. We'll start with a combined everyone in the session 90 minute session on day one. Identify the topics during that 90 minute session and who the session leaders are for the set the topic sessions and then during the next two days. We'll have subsets of the group meet for topic specific discussions, then gather everyone back together for a full group session to hear the summary of what happened so start together, split out and together. And, and here are the proposals and you'll notice documentation figures into the list as does Google summer of code as do lots of other things. So Zenab and Kristen for instance, I would love to have both of you attend these these sessions, particularly the open and the topic session on documentation if you'd be available. Your input would be highly valued and your insights would be a great help to the to the group. Sure. Sure. Okay, then, in terms of of just looking for your feedback and that's really it on this topic. I don't think we should take the time in our meeting today to review the document in detail but if, if you or if either or both of you could review it, I'd be most grateful. All right. And just like actually a question that point of clarification is this like every every in Jenkins is it is it's trying to invite every second Jenkins to every SIG and every basically everything at the it starts with officers. So the security officer and security topic infrastructure and releases, then goes into SIGs. And what we'd like to do is invite all of them to come now some of them, some of them may not be there you know this will be based on who's interested and who's not. But we were exactly if your schedule doesn't allow it it doesn't allow it. Great. Okay. Perfect, because that's the cool part about actually kind of like where documentation is going because it's such a great thing to pull everyone together. Just from that perspective, but sure. Agreed and I think you're right that it's a great opportunity for us to to remind people that you can contribute in more ways than just writing code. Right. All right. Okay. So one of the challenges there is there's a question inside the document about how to do online scheduling if you've got a positive experiences. Oh, actually Zina be yours may be a good one. If you've got experiences in your work scheduling the she code after she codes Africa sessions. I would love to get insights on. Hey, how do you schedule groups effectively so that they actually meet successfully, etc. I don't know if he is in that document but I have relatively little experience doing that well. So would love your insights. Okay, I'll go through and see. I have any. Great, thank you. All right, so then let's talk about pull request progress. Now it's time for the embarrassment phase where I haven't reviewed a pull request that's been open for two weeks and that's terrible. Sorry about that. Zina, thank you very much for creating it. So images and text ready to go ready for a way to show. Oh, this looks looks like great work. Thank you. So let me just put it in Mark or Kristen to review and merge. Thank you reviewers. Kristen, I don't remember do you have merged permission to Jenkins that I own. I might. It's been a little bit that that's why I'm like, I think I do but I don't know if anything has been cleaned up recently. You know what I'm saying, right. Great. Okay, so let me check. I'm going to set my goal by next meeting. So that so that I don't have to hang my head in shame at not having having done that review. Thank you very much for doing that writings, you know, that's been, that's much appreciated. All right. Any, anything else on that pull request. Nothing else. Then on the, the scaling Jenkins on Kubernetes pull request, I haven't had the time yet to meet with Kristen to get her coaching on how to do how to resolve the complications that I had in trying to work through it. So that I will hope I'm going to set my goal to by meeting two weeks from today. I'm sorry to give myself more time there but because I had some complexities I suspect we've got to align my scheduling Kristen's for her to coach me on the stakes I'm making. Sure. However, it's fine whenever you're free or just kind of let me know and I'll see what's going on. Great. Excellent. All right. Anything else on pull request progress. Okay, next steps for Jenkins documentation. One for me when I when I think about is. So we've got an open question from Daniel back as he asked a very good question or made a very keen observation is his question was hey, Mark, is there any work to make the Jenkins documentation. More structured and more organized than than the current collection of things that are starting to adopt. It's starting to feel more disorganized than it was two years ago, for instance, what's happening is new content is arriving. So we need to add an uneven pace base and with, and with uneven quality. So many things are copied from the wiki without without major edits, and they needed major edits. So those those that was his question my thought was, should we, we review the docs in an office of the docs outline. In office out in these office hours, and discuss how we think things should be revised structure discussion. Propose revisions propose additional content topics that are that are currently missing or weak. So basically what it is is with with the two of you be willing to be part of a documentation inventory exercise. Inventory review exercise if I brought a list of something like that would you be willing to participate and say oh I think we should do it this way or that way. Yeah, sure. Yeah. Yeah, I just something I have been looking for was looking to help with anyway for the documentation sake so yeah I feel bad I have not attended many very many of the sick meetings recently. So didn't really know what the progress was. Well, and this one I think I think office hours here this session is perfect, because hearing hearing Kristen from you and from Zenab on. Hey, these ideas work well together know these not so much. That's that's a great way for us to collaborate and identify. Okay which things are more interesting or which are less. So, how about we take the following mark to start something and share with others for more feedback. Our dog. Good to start somewhere right right well well because I had as an example I had a flawed concept that we should split the documentation into user guide and admin guide. And I looked at it after two years I think I've realized I can't tell the difference between user guide and admin guide. And I look at the free BSD handbook and they have only one. It's for users and admins. And so we're and remodeled after that so it's those kind of things that I think I'd like to discuss with the two of you, but I'm not ready for it this week it'll it'll need to be a few weeks out. I'm not needing help coming up with that list or like starting somewhere or like help him look at the BDS handbook. Yeah, or just let me know. So, because BSE handbook because yeah that's a huge undertaking of looking through all of our, all of our documentation. Right. And it's nice to finally be at a point though that we can actually even have these conversations too. Well, well, it's, it's, it's impressive how much information we've gathered in 15 years of now, almost 16 years of running the Jenkins project there's a lot of information, and organizing it is a big job. So, you know, I didn't actually answer the question what's next yet this is just trying to identify what's next. Do you think. Yeah, and also. Okay, great. Okay, great. Super. Now the next topic was we know that there's a big gap for Kubernetes documentation still right there's the world can't get enough of Kubernetes documentation in general there's just so much, so much of interesting happening in that space with open shift and with various Kubernetes releases and the transition from using official Docker images to using container images that are Docker compatible but not necessarily generated by Docker all the all sorts of interesting things there. So, in specific areas where you say, ooh, I would like to see this as an enhancement in the Kubernetes documentation or Kristen same question to you. I think the first thing first, I think only because most of the work we worked on during the Google system of the program was majorly beginner or non production content, because I don't know if you notice someone posted it with some kind of documentation is great. But the content is majorly you are not really production. I think it's a great idea if we can work on something more advanced for more advanced users. As regards Jenkins on Kubernetes. So, I plan on doing a kind of research to see content that most suitable but I've not been able to do that yet. But I think that's one suggestion that I have. I like that I like that a lot so more advanced use cases are are very interesting right and they certainly are. We know that there, there are people who are looking for those. And that's a very good example of the user who said hey that the initial documentation is great but it's mini cube centered and most most production installations will be using something much bigger than mini cube. Okay, good. It's good to have something I think it was still worth it like it was really good to even have kind of the basics of getting started but. You're right because I actually had to reply to treat and I just made mention that considering the fact that we didn't have any content on Jenkins on Kubernetes before it made sense to actually start from the basics then go right up to more advanced content and that's where it's going but obviously it's in Jenkins documentation roadmap to have more advanced content as time goes on. Definitely. Good, good point and you you just mentioned something that I had not even thought of we should look at the Jenkins roadmap while we're here, because that may give us some other hints what what things have already been identified for next steps good yes. Okay. So now in terms of the more advanced concepts around Kubernetes you you noted Zina, but it needs some more research. I'm a customer thinking of things like ingress as one of the common hotspots. Are there other things like that. For instance, I don't know is it is one scaling decisions into split and when to and when to combine. And that's not really that's not really Kubernetes specific even that's more of hey when is your Jenkins controller so big that you should split it out. Kristen any other insights you could offer there on likely hot topic areas. So is there anything about open shift for instance versus bird versus Kubernetes. More. More generic Kubernetes right, or maybe it's open shift versus EKS versus AKS versus whatever IBM's thing is called. And oracles and you know, choose your cloud providers, etc. I'm trying to think of other types of content here. Did the, or says you know when you were someone mentioned that they did they mention anything they were looking for in particular like that. So I'm not in particular the only observation he mentioned was that it's the documentation was mostly centered on using mini Q. Exactly. Obviously will be used in production environment so I think the solution to that which will be probably releasing an alternative to mini Q production environment. I think that's a good case for building out more of those solution pages. So like I know that this is working on the Amazon. Yes, it's like, oh here's like getting started, and then great now that you see how it works, like the basics here's how to get it. You know, here's the Amazon page like here's Google, here's open shift that just like anything we're just kind of continue to work down there. Yeah, that's ingenious. Yeah, so Amazon, Azure, Google, etc. you know, IBM oracle, all of them. They're, they're a bunch of cloud providers digital ocean. All sorts of dot dot dot. In case there's anything like a gotcha or for each of the environments because right like the basics of the community like how communities works and I thought it's gonna be the same everywhere. But it's like, oh here's some tweaks that we had, you know, like some, and especially this is a good chance to get from experts and you know people in the community who are using it in these environments to chime in. That'd be interesting thing like how do we encourage people who may not to kind of help contribute in that way, right, like maybe they're like oh I'm, I don't feel like I can write a whole document about something but I'd be willing to offer tips and suggestions. That's a good way to gather stuff. Well, I so hey we've, we've actually got, when we have entry pages like that we've got this thing that it's not terribly well highlighted. But for instance, if I look at the installing Jenkins page and let's look at Kubernetes. If I jump to the bottom of this page there's the improve this page link. And it will put me right into the place where I can edit directly on that thing. Now, maybe we could do as simple as remind people somehow hey look, you know what you can propose edits, it's just this easy. That would be, that would be maybe a really cool thing to highlight just as a, you know, encourage people to share their knowledge and it's showing them yeah it's not complicated. I'm sorry. I think I missed, like, how did you get this. Yeah. Okay, very good. So I love you saying that's enough. Thank you. That was excellent. How did you get there. Okay, so what I did was I went to the installing Kubernetes page. Right. So here is one of our pages and it could be any page but one of our pages. And the very bottom of the page on the on the bottom of the page is this improve this page or report a problem. So if I click report a problem. It puts me into submitting a GitHub issue. But if I click improve this page, it will take me right to the editor for that page. So I can, I can edit directly now. Now, if I remember right there are some, some hidden complexities in the in in this particular because we've got some reusable content that we're doing right here. Right, we're doing content reuse, and because we're doing content reuse, they may say, Oh, I didn't find the page I wanted because it's inside the reuse content. So, but, but nonetheless, there is something to be said for Hey, if you just actually maybe that maybe I just described it. We need a way of allowing people to jump into the reusable content for this page because the bulk of this page is in this underscore Kubernetes page, I think. Yeah, so, or if they say, Oh, I've got a setup wizard problem. Okay, we need to find a way to take them. We need to. Yeah, actually, maybe that would help us with the visibility because one of the problems I have with getting people to read this link is it's at the bottom of the page. What if we decorated each heading. Right now it's decorated with this hyperlink. What if we had a pencil right next to it in addition that would pop them into the editor for that section. Yeah, maybe that'd be good and that also highlights that yeah that you can help contribute. Right give them a sense of Oh, oh hey, not only could I I can I can link to it here but yeah so let me make myself a note of that I'm not sure if it's even possible but could we encourage more questions adding a pencil icon at the same location as the hyperlink in the same. Sorry, just back to back to our original question. Kubernetes documentation. Does this feel reasonable to use enough I think you've described very well what we should what we should want to do and the research on what content would be most useful will be a great help. So I think I'm going to answer this. Now, at least from all this. I kind of like have it to do already to find out more and more content to be useful in the documentation. Also, I think the solution page also would really help with this because taking existing solution pages I could see that there are also links to other resources outside Jenkins documentation that help users. Yeah, exactly courses video tutorials courses outside the from from outside companies. Yeah, exactly. Good. Okay, super. Anything else on either of the two Kubernetes topics there the documentation the documentation or the solutions page. I remember correctly, you know, we don't have a solutions page right now for Kubernetes right what we have is. We have let's see where the solutions pages we have Docker right we don't even have a page so this is a fresh start. The next topic was Jenkins roadmap, and I wanted to take a quick look it's been a while since I've looked at the Docs roadmap and I am. It's embarrassing to admit that it's been a while since I've looked but if we look at. So Jenkins on Kubernetes is current project admin guide overhaul user guide improvements and solution pages okay so we've talked about all those topics good. All right so that's really good. So log automation is in. That one is now done. I need to fix that. Okay. What else we got. Okay, good so and Google season of docs 2020 is now also done Jenkins on Kubernetes for me I feel like that one's still in progress because we think we've got more to do there. Okay, if we leave that one in the current list rather than putting it. Okay, great. And oh, that's another one agent terminology cleanup that we hadn't talked about so terminology cleanup is certainly certainly a place that many can help with terminology corrections. Okay. Great. And then last topic for me on on this, this where are we going this Jenkins wiki plan actually is part for me of the, the question about Docs organization because the wiki is a crucial contributor to this documentation inventory review. There's a lot of content there from a lot of with a wide variance in quality of the material or accuracy, but part of that is review the content and then decide where should it go so for me it's a it's a perfect fit for this proposal to let's do an inventory and let's talk about the inventory as a group. So the, the, the other parts of that plan are when do we migrate and turn the thing off. And that I'm less concerned about, because it, it's a lot of work to turn it off and make sure that everything redirects correctly and not a lot of gain because we don't actually spend that much energy maintaining this server. So it's cheap to maintain right now and expensive to stop. Okay. Any, any other topics with regard to next steps, what's up for document a Jenkins dogs. Um, so something else just came to mind about getting more contributors to Jenkins documentation. Definitely a page on Jenkins.io that explains how new contributors could contribute to Jenkins documentation or a document somewhere that much experience the steps and probably leads to this roadmap for people to be able to see. This is what we're currently doing. This is where we have plans for these things. Because it's also very important to try and have this information. If not in one place, but in close proximity so whoever wants to contribute to the documentation and easy to get all the information. Without getting this courage from having to look around and try and find the way around. Good. Okay. Good point. Yeah. So, so let's, I mean, we certainly know one of the experiences from your experience, Zina was that contributing to documentation is not as fluid for a windows user. It just isn't we need to improve that. And so that's that's a good one for us. Let's go to we do have. Let's go to participate page here that is the our entry point. Oh, whoops, participate. It would help if I could spell directly there. This page has document on it and this takes us here. However, I suspect there are still, well, for instance, featured projects probably needs an update newcomers likely needs more. But that this takes us to, oh, good. It does take us to GitHub, not to the wiki wiki that are not to the gyro site. And, yeah, that doesn't help nearly as much because we don't write with markdown. Okay. So good good insight we need to we need to improve. One of the things that the Jenkins governing board has expressed concern about in their most recent meeting was, let's improve the new contributor experience. Now, Zina you mentioned, you mentioned what tasks might a new contributor take is, would you be willing to test drive with your eyes to see if, if this material is a good recommendation of things they might take. Or is. Sure. So I think one thing that would really need to add to the contributor talk is how to actually set up Jenkins because I'm not really sure that information is really explicit anyway it shows how to on I think on the read me file or something. And it shows how to run make run and all that but it doesn't really go explicitly into details as to how to set it all and all that we don't have it. Right. Right. Absolutely. I remember when I wanted to start contributing and looking at the contribution guideline. Yeah, building. Right. There's so the building thing here is is nicely suited if you've already got your system ready. But if you're a brand new contributor you don't have your system ready. Exactly. Right. So there's Windows users I think of others like me free BSD users, or Mac OS users, or the, and some of those it may the answer may just be sorry you can't do that. Because right now it uses a if I remember right we use a Docker image and that works for Windows and it works for Linux, but it won't work for these others. Maybe it might. Christian, aren't you a Mac Mac user. Now I'm a Windows user. Oh okay all right so so we'd we'd have to check but I suspect in terms of our, our, our population we're our first population is likely Linux is current developers, and then then next is windows, and then going down from there. And, you know, you, you are the excellent sample of this one. Yeah. And I'm embarrassingly the one that I'm sitting on a Windows box right now but I do all my documentation development on Linux. Oh, and Oleg is, is a Windows user. Yeah, I do a lot of I live a lot in the, the Linux shell. Yeah, for a lot of my development. Embarrassingly Schizophrenic right. Oh yeah, let's see the fact that I actually work in two worlds. Yeah. Okay. Good. Anything else you'd like to suggest there on encouraging contributors. Right. So, last topic I had was just a reminder that Google Summer of Code is coming. It's the application is we will submit the application mid February. We need more project ideas and we need more mentors. And this is a link to that that page to if you're interested in being involved on the coding side of Google Summer of Code. Sorry for a 45 minute meeting I didn't actually expect to spend so quite so long on our session. It has this session been too long for using how do we need to limit ourselves to 30 minutes. All right. Any other topics we should cover before we end our session today. All right, thanks everybody. Talk to you in a week. Bye.