 Welcome to the Jenkins documentation special interest group meeting. It's the 24th of July 2020. Today we've got several topics. Let's go through those. I'm going to start sharing my screen. And we'll take a look at the topics and work through. So we're going to review review the agenda today. Report on previous action items. I have the action item to create the doc sig blog post to highlight our current progress. We've had great results on. Plug inside improvements on all sorts of other areas that need. The highlighting. And we're going to reuse this as part of the CDF graduation at the end of July. And included also on Jenkins.io. And we've also included an open action item on our GitHub apps and plugins that use them that Oleg will take care of so that people know which apps we can use and how to use them well. And I've completed the addition of the meeting URL into the calendar. We'll get it in the Jenkins.io site later today. And we've got mentors review the Gula season of doc project proposals. So we also have ongoing effort to. We've also included a community bridge mentorship program. That effort will not happen until after we get started on Google season of docs, but it is in progress and get being given some thought. Grateful to those who are attending our docs office hours. We had four who attended office hours on Monday of last week. And three who attended yesterday on Thursday. So we're willing to change those hours as needed. Grateful to have people helping. In terms of the terminology updates. Terminology voting is in progress. And on the terminology proposal chain, changing master to something more appropriate. The advocacy and outreach is handling that. The voting will continue until July 29th. And then the draft. The draft will continue. And then the term and its board will select the term that should be used to replace the term master. We're also delighted that Google season of docs. We've received a number of very effective proposals for projects. Those projects will be reviewed. And the reviews will be submitted to Google by July 31st. And after the July 31st submission. We're also pleased to be able to provide an overview of the results that have been notified of their. Of the project results. Zina, great to have you with us. I was just working through the agenda. Last item on the agenda. And then maybe we can ask if you have questions. Okay. Thank you. Thank you. Thanks for joining. So we've got GitHub issues. So this is the data section of our monthly meeting. So we're working in the organization. Are we showing healthy patterns of behavior, et cetera? As an example, our number of GitHub issues has decreased since last month. The number of open GitHub issues has decreased. And the number of closed GitHub issues has increased nicely. About 20, 20 plus issues were closed. And we only have 67 open, whereas before we had over 70. In addition, we're grateful to the Linux foundation. They're providing some metrics on various. Pull request statistics. Are in this particular graph shows pull request time to engagement. That is the time from initial submission of a pull request until the first response. That shows that someone has begun the process of looking at it. And we like this one to be under one day. And what the data shows is that the median value is well under one day and has been well under one day for, for many months. So that's a good sign. Time from PR open to merge. Is not quite as attractive in that it's showing. We've got an increase of time to merge. Going from what used to be roughly two days. We're pushing more towards taking us up to four days to get pull request merged. So that's an area we need to improve. Our median is still, still reasonably low. It's the median is still under 10 hours. But the, the 80 percentile or 85th percentile is, is going upwards. And that one we need to do some more work on. In the last month, there have been 64 merged pull requests, and we've closed in the last month. We've closed 65 pull requests. So nice progress. Now, we'd love to put topics on the agenda. Are there any areas where you would like to, to have specific questions that you wanted to. Review. So the question was, is for the user pages that are currently on wiki. That are currently in migration process. The issues on github, do they cover all pages on the wiki or one has to go to the wiki. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. So one has to go to the wiki, check the page to find out which one is not yet on Jenkins, will and might migrate. Or... You just go through the issues and pick up one issue that states, okay. This is for migrating. For instance, like remote assess API. There was an issue created for that. So my question here is, issues created for all pages on wiki or just some of them? Good question. Very good. So our issues created for all wiki pages and the answer is not yet because there is a triage process review process that is required before we decide we decide where to place a wiki page in the Jenkins.io infrastructure in the Jenkins.io site. And which content should be migrated and which should not. So very good question. So let's let's take an example. There is a triage spreadsheet triage sheet that Mark uses that I've used to record which pages have been triaged which pages have been reviewed. And so we could take a look at that now let's see if I can find that really quickly here. How about wiki conversion progress. Maybe that's it. Yes, this is it good okay so I'll embed a link to this sheet into the meeting notes you know so that we've got it. So here's the triage sheet and what I do there is when I've reviewed a page and created a GitHub issue for it I make an entry in this sheet. And the reason I do that is this access count column here. Maybe we should make the sheet a little more readable there. So this access count is an access account of a number of times the pages page was accessed in a 90 day period. And so what we did is we intentionally said let's migrate first the pages that are most frequently accessed and let other pages wait. So if we look here you can see for example that pages like how to run jmeter at row 72 is in that 90 day sample period was only accessed 4000 times. Now that's still lots of accesses so it's interesting, but it doesn't yet have a GitHub issue. So someone would need to triage it. I mean, the others above it have GitHub issues and on some of them I've made notes about which things are in progress which are done. So, so if you find a wiki page that you think, oh, this is one I would like to migrate. If it does not already have an issue in Jenkins.io you're certainly welcome to create an issue. There's actually a template on the Jenkins.io GitHub site, which will, which will guide you into the kind of information that's needed for that. So as an example, if we go to issues here and if I click the new issue button. Migration here is is it provides a template of the kinds of information we need to begin a wiki migration project process and it will ask which page are you migrating. Where should it where should it go. What are the notes that should be added about migration and then put additional comments there. What we've found, particularly as we get further along in this wiki conversion process is that there are some pages that require quite a lot of work. Other pages that should just be discarded. Other pages that are are of a portion of the page is useful, but the entire page is not useful as is we have to make significant changes to make it useful. That's that those are the kinds of techniques we're using right now we review the pages here and put notes into this sheet when a review is is done, and then go forward that way. Did that address your questions you know. Yes, it did. So, um, well, I think, while I was working on the proxy documentation, I think I saw another sheet. I'm not sure if it is this with pages like this. I think that had progress or something if it had been merged or it had a progress column to show if it had been merged and all that. So I was looking for a page and issue a GitHub issue to work on and notice that there are some issues where you have someone. Okay, I want to work on this. I want to work on this. The same person probably on like five, six, seven issues. I want to work on it. I want to work with person had indicated interest, but I don't see any poor request or any work associated to that issue ongoing already. So is there a way it's like probably okay one for one person I believe at a particular point you shouldn't like indicate interest or more than two, three issues at once when you're done with that. You can move on to other so other people can also have, you know, the opportunity of working because when I see an issue and I see someone has already indicated an interest I wouldn't want so there won't be any conflict. But in a situation where I've seen one person indicating interest on like 10 different issues at once and what has not started on the issue. It's, I don't know. I don't know. But I think that was one of the reasons why I decided to start working on plugging documentation. When I noticed that most of the issues already had someone who has indicated interest. Good question. Yeah, so how do we handle issues that are assigned but not making progress. Because that's that's a very good question and what what I think we should do there is if you see something. There was a there was a busy period during late May during the hack fest. Had many people who who said I want to work on this but then later decided oh no I'm not going to do it and did not did not indicate that they weren't. It's not uncommon in our open source world to have people who are who become unavailable and may not tell us they're unavailable. So what we do is then so hack fist had many many has many examples right and just place a comment on an issue that looks idle. And ask, ask if the issue is is being actively work actively developed. There we go. If after a day or two. There is no response. That'll be my trigger. That will motivate mark to unassign the issue. Because we it's difficult to know the assignment of an issue in GitHub is just a convenience for me. There's no way to see which ones are we have someone that said they were interested in not. So, we can, we can easily unassign, and you can work on an issue whether or not it's assigned to someone else. So the idea there is let's let's take some examples I just did one of these yesterday actually, where there was a, an issue that had been had been assigned, but had not had any progress in a month or a year. I'm not sure which one it was but, but it, it's not an uncommon thing to see. Let's see. Recently update, let's try that. So this was, and I apologize I don't know which one it was that I was working on but there was one that had. Oh yes here it is good. Okay, this one I think was one that it had an assignee. And the assignee said, Oh, hey, I'd like to take this on. And this was my response but notice that Kumar harsh is not assigned here. So, it could be assigned but then again someone else could pick it up this was just and I finally got to answer this question. Okay. So does, does that help with clarity now I think you were referencing oh go ahead. Yes, it does. Now you did mention and this is a good page for us to note the plug in migration migration progress report page is a great place to go if you're thinking I want to migrate plugin documentation. But I think you were specifically interested in wiki pages that are not plug in specific but rather our general purpose documentation from the wiki is that correct. So I was referring to that but I would also like a link to this also because I recently started working on plug in migration also. So it's been nice to. Yeah, let's put that in so that's a different. Alright, let's put that. What if I'm migrating plugin documentation. Wiki to Jenkins to plug in repos and really that's a different migration in the sense that it's, then it's wiki progress. Which is one good link. And then there is also the plug in document the plug in migration documentation page that guides how to do that. There's the exporter here that can help with the export. It's quite a useful tool to have something that will provide the conversion for us it reads the wiki page and provides it as either map markdown or ASCII doc. And we've got video recordings of people doing that live so that we could refer to to that. And there is also a GitHub project that we use to track progress on that. And now I, I'll have to think about where that GitHub project is, because plug in docs progress I think no that's not it. Docs. This one, here it is. So this is a. This is a GitHub project, which tracks the tries to track the various pull requests through their stages in progress merged and released. I don't know that a contributor needs to worry about this but it's been helpful for those of us who are trying to watch progress to see how, how it's going. So there's a GitHub project that tracks plugins across the entire Jenkins project. Did you have other questions. Yeah, finally. When I was going through the resources before I started contributing I saw a template issue on JIRA for migrating pages is JIRA is the JIRA issue still in use because I'm trying to understand the link between GitHub issues and issues on JIRA also actually had one issue for the plugin page I'm currently migrating but I just wanted to be sure if that is still very much active. Good question. All right. And so there are two answers to it. The, and the two answers. JIRA is the, the most common track bug tracking system for four plugins, right plugins and Jenkins core. We've switched the Jenkins.io site from JIRA to GitHub issues. And, and so there are still issues in JIRA that are related to Jenkins.io, but we found for the documentation purposes. It's easier for us to do Jenkins.io work in GitHub issues we get more involved people they better understand how to use it, etc. If we use GitHub issues instead of JIRA issues. So, there are some issues some Jenkins.io issues still in GitHub areas still in JIRA, and they'll continue there until we close them. The majority of them though, are now GitHub issues. And that was one of the things we learned from the HackFest. HackFest showed us how much easier new contributors can contribute to issues on GitHub than on JIRA. It's, it's impressive how much simpler it was based on that HackFest experience. Does that, does that address your question? Do you have, Dean, further clarification? So, just to be sure, for Jenkins.io, GitHub is the primary source for issues, but for plugins, JIRA is still in use. That is correct. Okay, okay, that's fine. And there are, there are some security and there, for instance, the plugins, our plugins in Jenkins Core security process means that we need, there are times we need to be able to have a bug report that is hidden from public view while the security team or a plugin maintainer works on it. And GitHub issues doesn't really have a convenient way to keep a, an issue hidden from public view. We've got a very solid workflow that works really well with JIRA for that. Thankfully, we don't have security issues on Jenkins.io, and therefore it makes GitHub issues an easy choice for Jenkins.io. Okay. Thank you. Yeah, I think that's all my questions for now. Okay. All right. Thank you. Thanks very much for joining. That's excellent. Those are, those are, are great topics to have in the notes. The meeting is being recorded and I'll create an archive of the meeting and we will, we'll upload the recording later today. Okay. Thanks very much, you know, and we'll conclude the meeting now then. Okay. Thank you. Bye. Thank you. Bye-bye.