 So I've been kind of riding along with their thinking. Yeah, that's great. Super. So our first goal today was to talk through the Google summer season of Docs Retrospective. Yeah. So it looked like we got shut out of that. Correct. Right. And that was why we wanted to do a retrospective. Our hope is that the Docs group, that this special interest group will also be able to contribute significantly in the drought season of Docs. Roddick, welcome. Thanks for joining. Just press mute. Roddick, thank you very much. And I need to unmute. Okay, Roddick, welcome. Hey, hey, great. What's your space? Are there any agenda items that you would like to add? No, no, no. It's fine for me. I mean, it's the first time I'm joining you guys. So I'm just going to lurk for a while and see what happens and what you learned from the past. Before Mark, he's got two lurkers and he's the only one with a paddle. That is not a problem. Thanks very much to both of you for joining me. Well, Mike's not here and I'd like to be able to start crisply. I'm going to move his topic further down and when he arrives, we'll bring it on to the agenda. So that's what I propose is let's talk first about the Docs special interest group infrastructure. And that way we make sure that we know what actions the two of you and others who want to help with Docs can take specifically so that they can better assist with Docs. So first thing, let's talk about how we get more involved in Docs. And the first step is this join the copy editor's team and get help. So what I'd like to do is put an action item on for Ashton, definitely for you. Radek, I don't know if you're willing to accept the action item, but why to join the copy editor's team? I thought I was on the copy editor's team. Okay, so let's take a look. What I see is you are very good. Now, is anybody else from documentation on there? They are not. Oh, Tammy. Okay. But we've got more of your team members. So John Ha, for instance. Yeah, John Ha with Jenkins X and I think Kim Nylander. Let's put that as an action item. But definitely John Ha. Yeah, John Ha joined. Well, although, and I guess let me put an action item. Let's do this is that John Ha. I know we insert it as a comment. I remember this. So either Tammy or myself can reach out. And what John's got to do is he's got to identify how to contribute docs to the Jenkins X project. I don't know how to do that. And I think it's different than the copy editor's. It may be. Okay. Welcome, Oleg. Yeah. Hi. How do you look according to Zoom? Yes. Yes. So we are using KCDF account, right? Correct. This is a Zoom test right now. We're using the continuous delivery foundation test account. Okay. Mine is labeled as Chris and we're just test driving. Okay. That's perfectly fine. Great. Oh, that is a wonderful sound. Oh, like I love that sound. Oleg's got a copilot today. He does. I'm a favorite copilot. That's great. Yeah. So you will enjoy the meeting. But I'm connected from phone. That's wonderful. Thanks for being here. And welcome, Kristen. Great to have you here as well. And John has joined. John, we just assigned an action item to you to provide us some hints on how to contribute or learn how to contribute to Jenkins X docs. Docs. Because I think it's different than how we contribute to the Jenkins.io docs. So by way of agenda team, we had said we wanted to first learn from our mistakes on the Jenkins, on the Google season of docs retrospective. I submitted the application. We were one of 200 groups that applied. Only 50 were selected in this inaugural year. We weren't one of those 50. But Oleg had asked, hey, let's have a retrospective to be sure that we get better at doing this. And if there is a Google season of docs next year, we have a better chance of winning. So Oleg, did you want to leave that discussion? Yeah. I cannot share my screen now, but I can briefly explain what are the main weaknesses. So yeah, I spent some time going through accepted organizations. So our biggest problem is that we didn't really have the J-Sort landing page. Because yeah, almost every organization in the accepted list, they have created some pages either on their org site, so in each half a week, yes, whatever, but they had a kind of landing pages. And in the case of Jenkins, I believe that final submission was still pointing to the Google doc. Right, Mark? It was. That's correct. So it was, and that's a technique you've used with Google Summer of Code. We absolutely have landing pages on Jenkins.io for all the Google Summer of Code project ideas. Okay. Yeah, right. Otherwise, we would have had no chance to be accepted to JSOC. And that's pretty much what we were discussing at the JSOC meeting before the application deadline. But yeah, even if we could have project ideas in a free form, but we needed a landing page. Great. All right. So that seems like a natural outcome of this exercise. We're going to need on Jenkins.io a bunch of docs ideas anyway. So I like that. Great. Yeah. Another thing that, indeed, we had something like five project ideas. But for these five project ideas, we had only one project idea with listed potential mentors. So Google, when they were completing the application, they were unable to tell how many potential mentors we were able to find. And yeah, in such case, it's also not an advantage for an applying organization. Hey, and was that the project idea? I thought every one of the project ideas had mentors listed? No. Only one project idea fed mentors. For example, Jenkins 6 project idea didn't have potential mentors listed. Project ideas like let's improve plugin developer documentation. It had no mentors. And moreover, it had unresolved comments about, for example, meeting Daniel Beck, whether he would be interested without any response. Got it. Yeah. Just because this Google doc wasn't supposed to be a final doc, we would have been submitting. Right. So if I was reviewing this application, it would be a kind of yellow flag for me immediately. Yeah. I think we had John Haw as a mentor. We just apparently neglected to put that on the list. I guess. Yeah. Just think, well, and Oleg's right, we didn't have a formal page that would have rigorously listed those things. Yeah. And we, yeah, moreover, we didn't have links from this Google doc page to other documentation resources we have in the Jenkins community. For example, Jenkins CI docs mailing list. So again, it comes to the lack of landing page because what we have, usually we have a page with all contacts mentioned, whether it's special interest group of the project, we have the information on the Jenkins site. And yeah, for Google season of docs, community bonding is still an important part. So without application, probably it wasn't clear whether we bond potential tech writers to the community and which channels we're going to use for that. Thanks. Any other insights on? So I felt like I had also not done an adequate job on preparing the application. I just took your content. Oleg that you had done such a good job on, but then just pasted it in without putting my own effort into it. And again, no matter. Moreover, if you're doing retrospective, you took an action item to prepare landing pages. So yeah, I moved on to other things, but then you didn't have time to actually post the pages. So if you have said me that you have no capacity to post these pages, maybe I would have approached it differently and I would have created the content. Okay. Same for the Jenkins X, if we had known we needed one, but next time, you know, John and I both have access to contributing to the Jenkins X community pages. So if we need to create any pages, we can do that. Yeah. So these first three items and primary weaknesses, actually each of them could have been enough to not be accepted this year because, yeah, this year it was a high competition between organizations. Actually, I didn't expect so high competition because the season of docs, mailing lists, were not that active. Slack wasn't that active. But yeah, it looks like many organizations. Yeah, the announcement about JSoc has been distributed to all JSoc organizations. So yeah, many of them applied silently. And yeah, finally, we got a lot of applications number. Great. Okay. Okay. Any other insights that you want to share? Well, probably we could have facilitated the global season of docs more in the community channels because, yeah, I sent a couple of emails, but really we didn't do any focused advertisement in the community, mostly due to the lack of time because it wasn't parallel with JSoc, which was pretty hot. And yeah, I also had some other stuff to do. So yeah, maybe if we have facilitated better, we would have got more visibility, more project ideas, et cetera, et cetera. So when do you say community channels are you talking about the Jenkins users' mailing list or the Jenkins developers' mailing list? Are there specific channels that are under my head? Everything, including blog posts or whatever. So yeah, it depends on how much time you have. You can spend all time you have on promoting the event. Hi, everybody. Hi. I'm sorry. It's just coming in late and a bit distracted. Yeah, just want to comment on this retrospective. It just seems very one-sided. So we're kind of just hammering on all the negative things. But I think we should take some time to say what we did well as well. Yeah, we should do it, of course. The first item was just primary weaknesses. Yeah. I like to start with the positive. Yeah. Okay. Let's add an item for positives. Before we go on to the positive, I just want to say, I mean, I think it seems like, you know, Mark's lack of time to work on this, you know, kind of hindered some of the things that we needed to do to to compete with the other applications. I think that, you know, we can put that here and then, you know, next year address whether, you know, we, someone who can work on it during these times, you know, maybe if that makes it easier or allows us to get everything done. And, you know, with Mark being a consultant since he's familiar with this type of work. Yeah, for me, it was a bit different because originally I had time reserve for creating GSOT landing pages, et cetera. So yeah, I just moved on to other things. When Mark said he will do that. So yeah, first item. So yeah, maybe it's an action item for you, Mark, that if you see that you have lack of time, just let people know because we had a lot of people interested in GSOT and we could have a load balance at that. Right. Right. That was, I think that's the, I like that. Acknowledge the overload and pass action items. Others, I think that's very healthy. I think they're all like very good. Yeah. I continuously get overloaded. It's probably an action item for me as well. But yeah. Yeah, I mean, I, you know, I really want, you know, the documentation group to, you know, participate more in the community. And, you know, I had time to decide for them, you know, for both John and Petra to be part of this. So, you know, if someone on my team needs to have cloud these time dedicated to being one of the coordinators next year, I'm happy, you know, to offer that. I think that, you know, that we're going to spend the next year, especially on the Jenkins X side, really being a larger part of the community. You know, John's already attending office hours and has a lot of proposals in place. And we certainly want to do the same for Jenkins. So, you know, maybe, maybe that's the, that, you know, that's a change we can make next year. You know, I know Tracy was, you know, the, the second coordinator or whatever it was called, but I'm happy for someone on my team to be that. But, you know, I don't, I don't want to, you know, take it away from Mark if he, if, you know, he feels strongly that he wants to do it at his own time. But I'm just putting it out there. I can dedicate, you know, cloud these time to it. Great. That sounds very promising. Yeah. And maybe we also could get some support from a CDF next year because there are four projects. And I believe that all of these projects would benefit from, would benefit from better documentation. So this year it was just too early to even consider coordinating it in CDF. But maybe next year we could try doing so. Right. Very good. So positives, I'm going back to that. Yeah. I apologize, Tracy, but I think I learned much more from discussing negatives. It's very kind of you to want to do positives, but there's much more education for me in talking about the things we did wrong. Yeah. I think you have to put them in context. Absolutely. Yeah. We have actually many other people on the call who participated. So maybe somebody else would like to say something about positives for ourselves, of course. I think positives, I think the idea, the topic ideas we had were really good, right? We were able to come together as a group and propose some great topics, both in Jenkins and Jenkins. It's like Kristin saying she thought the same thing. And I think we did not lack for mentors within this group. We just didn't do a great job of communicating that in our application. Thanks. Yeah. Now, one of the concerns for me on mentors is that I think we need some more facilitation for our mentors so that they can help with the actual process of things that are going on right now in Jenkins documentation. So we'll touch on that a little later in the meeting. Yeah. And I think I'll add just on the positives, you know, it sort of came up with, you know, not that much notice. And we did rally quite a significant group of people together. There was a lot of engagement from the community. People who don't necessarily get involved with other things had an opportunity to sort of say, hey, I'd like to be part of this. So that was really good. And, you know, it has led to the SIG. So as a trigger point for a documentation SIG, I think that's fantastic. And I also say, I don't know if this was shared earlier, but the feedback was that they had 200 organizations apply and only 50 made it. So, you know, in some ways, like until we get our application clean, we might not even know that, you know, there was nothing we could have done just 50 shinier ones. But yeah, just to get that application even done and people organize for that, you know, with a number of working in their spare time, I think that's amazing. We should be, you know, proud and happy with that. Yeah, I like that. Thank you. Any other items to note in the positives in terms of our retrospective? Yeah, one thing probably similar to DOX SIG. Yeah, the fact that we didn't get a substitute is sort was another factor which finally made me to seriously explore community breach platform. So it's something I added to the agenda for yesterday's Advocacy and Outreach SIG, but yeah, maybe we'll discuss it next time. But I'm exploring ways to have another program maybe in autumn. And yeah, doing something for documentation could be feasible. So it's not limited to coding like JSOC. Any other feedback? I'd like to shift gears then. We've only got about another 20 minutes. And I wanted to be sure that we have a chance to take some specific topics. Oleg, are you okay with us shifting gears in terms of the retrospective? Would you like us to capture some specific action items? Well, I think that we didn't formally discuss what we want to improve, but actually we can discuss it at the next meeting. So everybody can think what you want to improve and then we meet again and discuss how to improve the framework. Maybe by this time we will have a six-kiloton so that we can set it for the next meeting. I like that. So basically it's attendees and others to pose specific action items based on the retrospective. That's our way to say it, Oleg. So then I wanted to steal some time in this meeting agenda to encourage us in terms of the DOC SIG and specific things we can do to begin contributing to the Jenkins stocks and Jenkins X stocks. So that was my proposal on this next segment is let's find ways that those of you who are on the call, all of us on the call, can become more actively involved in helping the Jenkins stocks efforts and the Jenkins X stocks efforts. So first piece is I need to follow the instructions that have been given in the Jenkins enhancement proposal for Jet4 that say how we create the DOC SIG and we're in process of doing that. That pull request needs to be made. That's the best you can do in joining this GitHub copy editors team. So you'll find the hyperlink there. This grants you permission to assist with reviewing submissions to the Jenkins IO DOC site. And as mentors, one of our key roles is to review the contributions of others and help them get those contributions submitted to the Jenkins.io site. Now John or Tammy, I don't know how to contribute to Jenkins X documentation. Would you be willing to do a blog post or take on the action item to do a blog post for us? A blog post for which blog? For Jenkins X blog. What I was thinking is we need a place where people can go who want to contribute to Jenkins X docs and know how to do that. So I'm thinking that we need, John if you could look at the Jenkins X community docs right now and find the section about contributing if it doesn't exist, write it. Maybe it just doesn't even exist at all and then write a CloudB's blog on how you were able to join the community like what steps you went through. Join the office hours, make a proposal, start doing pull requests and then getting accepted into the proper GitHub groups. There's a Slack channel you join. All of that stuff I think would be a great CloudB's blog that then would link to specific instructions on how to contribute Jenkins X docs on the Jenkins X community site. Sure. I've been taking a few notes about the Jenkins, the JX-Docs repository and I can write a blog post about how that's structured and how to contribute to it. Sure. Yeah, I think that'd be great. I'll add it to our agenda to talk to during X one-on-one but I think you probably need a GitHub issue in the Jenkins X docs repo and then an internal Jira for the blog post but that's certainly something we can do. Okay. Two questions from me actually because I took a look into the GitHub proposals right now so I don't see in the current content 6 according to the JAP4. I don't see the JISOD there at all and the other thing, the copy editor's team that is linked, I actually cannot, I get a 404 so I don't see a way to request access to that. Same here, I get a 404 on that. Yeah, because in order to see this team you have to be a member of Jenkins infrastructure organization. So the best way to request access is actually to just send emails to the Jenkins developer Yeah, so I think we should, maybe we can put those instructions somewhere in the blog post. Yeah, I can put that on the read me of Jenkins.io for example. So there is Jenkins.io on the page and we could just put it there. Yeah, that's a good place. So Oleg and is the copy editor's team the right choice for that? Well, so in order to add a person to copy editor's team I would like to see at least some track of contribution to the Jenkins organization. But again, you don't have to be a member of copy editor's team in order to review changes. You can just subscribe to the repository and that's it. Once you subscribe to the repository you will get notifications about new pool requests. So then you can just review them and eventually we can grant you merge permissions. So copy editor's effectively means merge permission. Okay, so then what that's really saying is it's premature for many of the people on this call to request access to copy editors. It'd be healthier if they simply began reviewing pool requests. Yeah, it's my interpretation. We don't have, so we have a kind of implied policy for Jenkins score but yeah, Jenkins score is a bit, well, it's more risky. And for copy editors, most likely members of copy editors also need to sign individual contributor license agreement with Jenkins. Because once you get merge permissions on Jenkins.io you can screw it into your website. Got it, right? Which really means for us as reviewers the most important thing is just begin reviewing pool requests. Yeah. They really need to, okay, so that's a different focus. So begin reviewing pool requests is much more important actually than becoming a member of... Yeah, I just wanted to say that maybe it makes sense to define copy editors process actually as a job. Assuming that there is somebody with this job to be delivered. Because yeah, we need BDFL to assign the BDFL delegate and other such things. And it's not trivial for me. Do we need to do it as a job or just sounds like the process is already there. We just need to capture it in put it in the contributing. Yeah, we can just put it in contributing for now. Yeah, I think that's just a nice on-ramp of, you know, start off doing pool requests, follow the repo review. You can send a request to the dev list. And here's the other things you have to do contributing. Okay, yeah, I agree with you. My job is on work there. Yeah. Kristin, did you have something you were going to say? Sorry, Kristin. Oh, it's all good. Sorry, I think I was starting to think about what else we could do for kind of part of this is maybe we can start looking at additional, like now since we have more time, additional projects or even kind of finding good documentation tickets for people who are looking to get started with Jenkins 2 because you have all this, like there's a lot of documentation out there and unfortunately on the website when I was going through and looking at some of this documentation, you could see a whole bunch of little triangle warning signs where it was just kind of exclamation points. This is to be completed. So maybe it's a good idea to start coming up with some, as part of maybe the SIG, some like tickets that are easy for people to get started with. Yeah, totally agree with Kristin. Actually, we already spent some time creating new friendly tickets. So there is a website project in Jenkins Jira and for the last October 1st in 2018 we created, yeah, we found to create maybe 15 new friendly tickets on the website. Obviously, we create more. Okay, so that clarified something for me, like so the website Jira group is the preferred place for things related to Jenkins.io Yes. Okay, more specifically Jenkins.io and there is a component in this Jira project called content. So I guess the most of you be friendly tickets will go there. When we have our page it's definitely make sure we think out to that. Right. Okay, so in the content project, and link to those two newbie friendly from the contributing committee. Thank you. Very good. Yeah, also we actually do have documentation tickets in Jenkins project, I mean Jenkins Jira project because we have a lot of documentation embedded in the Github repositories or built in documentation. So maybe we could also create a query which takes it into account. So I can prepare this query or you can create this query mark. So I went looking for documentation in the, in the, what I'm used to is the Jenkins project in Jira and wasn't terribly successful. So that's, if you're willing to do that, I would love to get some tutoring out of it. Okay. Yeah, let's do it maybe at the next meeting I'll probably spend an hour in order to prepare filters. And then if you just discuss it at the next meeting you can see what's missing there. Great. Okay. If you're interested in this topic any help you'll be appreciated. So we just need to agree on the label something quite good also, documentation and then we can prepare everything else. All right. Thank you. Probably I can also help with that. Do we have a central is there a central page that describes actually the current Jira projects and the tickets that should be used weren't when I mean for the previous points right that we wrote to use the website Jira tickets preferred blah blah and stuff like that. Do we have a, is there any page in conference currently that describes all the projects that are in the issues Jira? I don't think so. That would be useful I think for new commerce right? So Radek I'm wrestling with are you thinking a list of plugins or components? No, I'm talking about projects so like Oleg mentioned that there is a new project and there is a specific label under that project that is for sick dogs and like considering there are a lot of other six or ideas and stuff in that Jira I think it's useful at least for the newbies to look at the central page for people who are coming to this new I think it would be really useful to have some way to understand kind of history and context just how things have worked and how they are working what processes are in place how things are decided I know from my perspective as somebody coming to this new I felt like the decision making process was a little opaque and just not intuitively instantly understandable and it made me nervous about trying to jump in because I didn't want to step on toes Yes, good feedback I think making things discoverable as well in a kind of self-service way even I'm learning lots of new things but kind of going how do we expect people to discover this or find it figure it out for themselves Exactly, because I'm less concerned about the history and why things change but I'm more concerned about how they work actually right now I always spent for instance with Jenkins I spent the other day looking where the security things are written down in the codes that are showing up in the UI because I couldn't find it anywhere in the documentation for the developers it's fine to dig into the codes but if we have concise documentation that it saves time So, Radek, just to be clear are you okay with that being conceptually as part of the DocSig on Jenkins.io or was there a different location I haven't created the pull request yet for that so it's a good candidate would that be okay or are you interested in getting a different one? I don't know how it works up to now but for me it's perfectly fit Okay, great, thank you I was hoping that was a good fit Alright, very good So that DocSig pull request that's my action items so let's just put this one on me as well other topics other issues with regard to DocSig infrastructure So I've got one more which is monthly meeting frequency we've got about five minutes left on our scheduled time Yeah, oh Go ahead Oleg Oh, sorry Yeah, I just wanted to answer your previous question so I think maybe for the next meeting we should discuss Jenkins plug-in site because it's one of the ways for users to get documentation about plugins and right now the state of this plugin site is far from optimal I'm not sure whether it's exactly DocSig but it's something we could discuss Yeah, so just a little bit of history that I understand about it since starting in September DocSig owns the site because nobody else does because it's part of go.cloudbees.com We know there are Sorry Yeah You're confounding two topics Sorry Oleg you secret I thought you were talking about the thing you asked about earlier on Slack you're talking about the community one Right, yeah, so Oleg's talking about plugins.jankins.io I think did I get that correct Yeah So right now since we had public special interest group meeting I'm talking only about plugins.jankins.io and the current state that this plugin hasn't been really maintained since Jenkins 2.0 and there is definitely something which could be improved there Oleg, there are things that could be improved everywhere Well, yeah, that's for sure I just propose to add it to the next meeting, so the site is not bad, but yeah, there are some things which we could change in order to provide access to the plugin documentation and to information by users Right, so I think kind of a lot Sorry, go for it, Mark No, Kristen, you have the floor I was thinking like kind of along these lines maybe something we should also look at defining in the future is just kind of a standard about how we kind of want to play things out so it's a little bit easier for people I know that the whole, we want it to keep it like everyone documenting everything kind of like keeping it all over the place but maybe like include in some of the plugins hey can you at least include like a common usage and like a one or two line description but just something a little bit to help us with figuring out which one is our plugin site I know that a lot of organizations will have a lot of those plugins and like the people who are working on them will have like a lot of documentation a lot that's something we should look at as a group too Great, excellent Okay, so consider that we'll add that as a topic to the future meeting and we can do research on it etc we can certainly use the Gitter Channel and the Jenkins CI docs mailing list for discussions on the topic without having to be in the meeting Excellent, thank you Okay, so we now are at two minutes prior to what our scheduled end time is one last negotiation here is how often do we want to meet and at what recommended time so the SIG requirement is we must meet at least monthly given the level of interest here I'm prone to recommend every two weeks rather than monthly and if we have to skip one for something that would be okay comments? Yeah, I'm fine with two weeks at least it definitely makes sense to have the next meeting in two weeks taking the discussion about you with friends etc so there's a lot of flow-hanging truths which we can discuss at the next meeting already Okay, good I'm going to take it as we're going to go for meeting frequency every two weeks until we decide differently because that works for me and given the energy level that seems to be in this meeting I like that Western Europe and Eastern Asia or given the folks who are on this call seem to be at the moment at least all in Western Europe due to a Western Europe time so do you want me to just do Western Europe should we do alternating back and forth so next week we do it in Western Europe time or next in two weeks in Western Europe and then four weeks from now we'll do something that fits better with our colleagues in China and Australia to discuss in the mailing list because I'm not sure what's Rick's availability for evenings but Rick definitely wanted to discuss some topics about documentation especially in Chinese and other so it's not necessary to have a special docs meeting for that because we can just go to Chinese localization but yeah let's just discuss it in the mailing list we'll do and FYI we're using Zoom as an experiment here rather than hang out specifically because it works better for those who are in China this is the experiment we'll see how it works we'll go forward from there I have one concern about using Zoom for such meetings but I will follow up with you Mark and with you Tracy later great thank you are there other urgent topics that we need to get we've hit the end of our 40 minute schedule 45 minute scheduled time are there things that you're concerned about that we absolutely must discuss if not I propose we end here and shift to discussing things in the in the online chat and in the mailing list yes