 Welcome to the Jenkins Documentation Special Interest Group. It's the 22nd of January, 2021. Let's review the agenda. We've got first item, report on previous action items. Oleg's not available today, so we'll skip that. Documentation planning is one topic that we'll touch on and then latest data on contributors and contributions with the addition of a new component into the data that we're collecting. So first topic, let's take a look at the documentation planning idea. So as a result of our office hours meeting on Thursday and prompted by questions from others in the office hour sessions on Mondays, we've decided that what we should do is make a content review and mapping exercise in the Jenkins Documentation Office Hours. What happened was Daniel Beck asked a very good question. He asked, hey, is there any plan to bring more structure and organization and clarity to the Jenkins Documentation? And I had to admit, I didn't have any plan. So we discussed it in office hours with Zinaba Mubakar and with Kristen Wettstone and they've agreed to assist with a content review and mapping exercise where we will attempt to find the best place and the best and the preferred structure for Jenkins Documentation that already exists and candidate material that exists in the Jenkins Wiki that could be converted and placed into the Jenkins Documentation. So Zinaba and Kristen have already agreed to assist and we'll ask our Monday office hours participants, Vlad Silverman and Meg Roberts to assist as well. So the idea is this, so what we'll do is we'll identify candidate content first by creating an outline of the current Jenkins.io documentation, the headings of the chapters, sections and pages that are part of Jenkins.io. Then create a list of existing Wiki content by frequency of use. That list, we've been amassing over time by collecting the Wiki access data logs every day for the last about 12 months. So we've got a pretty good sample of which Wiki pages are being read and which are not. Then outline a map of the content into www.jenkins.io and that means mapping the most frequently used Wiki content into the handbook. This is a technique that Jonathan Marise had done, had done this exact technique for us on a number of, Jonathan, had done this technique for us on a number of cases. And it worked quite well for us. It allows us to create individual tickets. Once we've completed this review process, we'll be able to create individual tickets for each page that needs to map and be able to identify the kinds of changes that may be needed in that page. Now, it's a lot of work. Jonathan spent many, many hours doing that work, but the result was we have the result is that we have a better definition of what should the structure of the documentation be, how should it look to users and what content should be placed in which places. That way we don't sacrifice the content we have available in the Jenkins Wiki as concepts and as ideas. And before it gets put into www.jenkins.io in the final destination, it's been through a good content review process and content preparation. The other part of that is to map the existing content on www.jenkins.io that needs to move location because there are some things that are not well placed in the current documentation. And we now have a technique to preserve the identifiers of those pages even when we move them. And that means navigator navigation that previously had recorded the URL of an identifier inside a page will still work. It will jump to the old page initially and then be redirected to the new page. That redirect technique will help us preserve the value of people's existing bookmarks of existing pages that reference that content and still allow us to restructure the content in those times when some concept belongs in a different location. We'll use that information, this new map of the candidate content to revise the Jenkins documentation roadmap. Now, one of the revisions here is that I had initially had the concept that what we needed was a user, I had had the concept that we needed a user guide and a separate administration guide. But the more I have looked at Jenkins content, the less clear it has become to me as to what is something that would be in the user guide and what is something that would be in the administration guide. So as part of the upcoming Jenkins contributor summit and in docs office hours, I'm going to discuss the concept that we go back to the original concept that is described in the Jenkins documentation that there is a single thing called the Jenkins handbook. And that handbook is the place where all things about Jenkins can be found. The Jenkins handbook concept is basically the same concept as the free BSD handbook. And the structure and conceptual are forced for concept. It's thought about in the same way that there's a book that you can see or a thing that you can see that gives you all you need to know about Jenkins. We'll review and discuss that plan during office hours on Mondays and Thursdays and make progress on it. It will also be reviewed and discussed in the upcoming Jenkins contributor summit in February. Mail on the contributor summit just went out yesterday. And looking forward to people's comments and proposals on how to make the contributor summit most effective. Now, in addition to that part of as or as a part of that planning, we've identified that there may be a case where we need to in the future create a read-only copy of a purely read-only copy static of the Jenkins wiki. That's part of this Jenkins wiki plan that's linked here. And the Jenkins wiki plan describes how in late 2019, spam caused us to make the Jenkins wiki read-only. And since that time, we've been making progress as we migrate the content from the Jenkins wiki to other places. Plug-in documentation is migrating into the GitHub repositories and Jenkins documentation. So things about Jenkins core or higher level concepts is migrating to the www.jankins.io site. Now, the motivation for this possible transition is that if there's a security issue in the confluence version we're running, we need to upgrade it or decommission it. And we don't want to lose the knowledge we've captured there. So, but it needs to be in a place where we can, where we can actually edit that content, make use of it. And that's the progress we've been using one page at a time. But if we were forced to, Tim, Jacob notes that we may be able to just capture a copy of the site statically and with that static site, decommission the wiki server completely, and only serve static pages. Now, how's our progress going? That's a good question. We're showing, we can see progress in one of two ways. So progress reporting. We can see progress in the, it's now included in the metrics as of today. That's wiki conversion progress. And the wiki conversion progress page is here on the Jenkins wiki exporter. And what it shows us is that we have over 1,100 plugins yet to migrate their documentation from wiki to GitHub. 600 of the 70 of the 1800 total have been migrated. So we've got one third of them that have migrated to documentation as code. So let's let me put a hyperlink there. 600 of 1800 migrated. And then we have another 60 plus PRs proposed pending. So the progress is, is admirable. It's a good, good win that we've made this, this far. We need to keep going on that. There will be more to more to work on in this topic as, as we continue forward in that migration process. Now, latest data on contributors and contributions. We've got 112 open GitHub issues. That's down seven from the number of open issues that were open as of last month. So we're moving slowly towards reducing those open issues. Many of those issues are transformation from wiki to Jenkins.io and their work that needs to be done. There are many more that could be created. So in terms of our other metrics, thanks very much to the Linux foundation for their dev stat site. Our time from PR to engagement is, is looking quite good still. And that we're very grateful to Markey Jackson and others who are very actively acting as reviewers. What this shows us is that across the last three or more months, our 85th percentile of time to engage with a pull request from its initial creation to engagement to some comment from someone, not the author is well below one day. We had one, one sample. That was above one day for the 85th percentile. Our median time is very nice. So people, we are obviously connecting very rapidly with contributors as they contribute new pull requests to the, to the Jenkins.io site. Other data is not quite as quite as positive. So time from PR open to merge is looking a little worse now than it was before. You can see an upward trend here at the end where in December, our 85th percentile was below 10 hours for us from open to merge. But now during January, we've gone upwards pushing towards, pushing towards two and three days before it, before we get that initial, that merge for a new pull request. Now the current state of number of pull requests pending last month, we had 32 pull requests merged. That's down a little bit from prior months. In the past, we've done 40 or more. We assume it's some impact from many people taking two weeks off during the end of December as their end of year holiday. We currently have 29 open pull requests with 3,723 closed. Many of those have been open for an extended period. It's, that's a, that's an ongoing issue that we need to resolve. We need to either complete those pull requests and close them or admit that we are going to merge them and bring them in all the way into the product, into the documentation. The plugin documentation conversion progress is a new measure that just added this month. We have 1,000 roughly to do 1,100 to do and 600 complete. So we're a little over one third complete in the process. Now we, we pragmatically do not ever expect to reach full completion, but there is good progress here and we'll continue the most popular plugins have already either made the change as shown by the okay here or have pull requests pending for them. There's still plenty to do, but you can see scrolling the list that the most popular plugins already have some documentation as code and that documentation is code gives the pull request submitters and others an opportunity to correct documentation and update it with their pull requests. So nice, nice improvement that the first to do on our list has less than 10% of the total Jenkins installed base as its count of installs. So big win. Thanks very much to everyone who's working documentation is code in their plugin documentation. That ends our session for today. Thanks everyone.