 Hi everyone, this is Mark Waite. Welcome to the Jenkins Documentation Special Interest Group Meeting. Today we'll review previous action items. I'll do a demonstration of plug-in redirection of the wiki and how you extract change logs with the wiki exporter as a way to highlight the progress we're making on migrating plug-ins from wiki to hosting their own documentation. Talk briefly about Google season of docs and then review the latest data on contributors and contributions. So let's get started first with that demo. So thanks to marvelous work by Gavin Mogen, he's now implemented wiki redirects for most of the plug-ins in the system. So the wiki documentation still includes some general docs like for instance this page How to Report an Issue and we'll eventually get this page migrated as well but the wiki is still readable for those who need the information that's on it. However if I go looking for a plug-in like the git client plug-in or the git plug-in so let's look for git client plug-in in the wiki. It's going to show me a search result and here it is and it shows a page that was updated September 10. If I click that link it will automatically redirect me to the actual plugins.jankins.io wiki site or plugins.jankins.io page. What you see here is plugins.jankins.io not the wiki and much faster renders quicker easier easy to maintain and in this in the case of this plug-in completely maintained inside the github repository for the for the plug-in makes it easier to maintain for all of us simpler cleaner and precisely version. More redirects will be added through pull requests to the Jenkins Infra project to redirect other plugins. It's been really marvelous what Gavin has done with the redirects to make things simple clean and fast. Plug-in documentation now appears sooner is easier to read and easier to maintain so how are we doing on our progress well up to this point over 260 plugins you see here two over 260 plugins have migrated completed the migration and released a new version using documentation from the wiki or using documentation from github not from the wiki thanks very much we've had contributions from students from plug-in authors certainly contributions from many others who are helping us as we transition away from the wiki for plugin documentation to plug-in documentation inside the github repositories the the charts here or the page here that shows us the progress is a great way to find a plug-in where you can help and you click one of these and it'll take you to a plug-in that has not yet been transferred so let's take the javadoc plug-in for instance this one if I go to its github repository we should see that hey no pull request and its documentation is not yet maintained in github it's instead listing it on the wiki this is one that could be trans reconfigured and reworked to use documentation in github instead of documentation on the wiki so in addition when we make that transition we need to be able to transfer the changelog the release history from the wiki to github because many plugins have tracked their change history in the wiki page the wiki exporter tool here when I click export this tool will offer translations of the wiki page into markdown or ascii doc so if we take that javadoc page and I just click convert here so this is if I go to my that confluence page for let's go to the javadoc plug-in here and if I grab that page I should be able to put this into this converter do convert and it will read the page from the wiki and present me that in this case in markdown here it is and notice here's the changelog so I could copy the content of this changelog into a pull request to the javadoc plug-in it's that easy that's straightforward it just works really well and then we get more and more of these things translated now in addition to that we've also got a project on github that is tracking our work as we make these this transition so you can see these swim lanes that show us here 18 pull requests that have been submitted to projects that are now released that with a version with that pull request inside of it merged in the merge column in the center shows pull requests that have been submitted and even have a highlight here approved you'll notice that it says one review approved so if you want to find a way to help here you could choose one of these that has not yet been approved review the pull request and note your approval of it that way the author the maintainer of the plug-in has one more person who said yep I've reviewed this documentation it looks correct and is ready to go so here's a great chance to use the wiki exporter keep keep a add a plug a changelog to the plug-in repository and then update the read me to refer to the changelog in addition to those efforts where we'll be initiating soon our application to google season of docs google season of docs is modeled somewhat after google summer of code but is focused at a different audience where google summer of code looks to to encourage students to engage in in helping the Jenkins Hill helping open source projects google season of docs is focused on writers and people who do not have who have professional writing experience but do not have experience contributing to open source projects and what we'll do is we'll offer up some projects that these writers might be able to help us with I'll create the initial ideas for google season of docs and submit them I'll be using a similar template or similar format as the google summer of code project uses in Jenkins so that we have an easy pattern to follow as we evolve and grow this we'll likely start small initially maybe one project or two projects and watch and learn to see how we can do better now in addition to google season of docs we've got as a concluding item the data on contributors and contributions so this first graph shows us that the time from poll request creation to first engagement by a reviewer in giving comments or feedback on the poll request and what you'll see is over the last three or more months we've solidly kept the time to give feedback under four hours for over 50 percent of the of the poll requests and in general time for feedback right now for the 85th percentile is still well under one day looking good the poll request process is healthy on jenkins.io we keep handling things as they come in get them deployed now time from pr open to pr merge is also holding nicely and looking good our median there is that we're well under 10 hours probably on the order of two hours for our time to from pr submission to merge and the at the 85th percentile we're still well below it one day as our typical and under four days for the last multiple months of staying cleanly below that that four-day limit in addition we've had good poll requests in the merged in the last month we've had 84 poll requests merged from 30 different authors and very grateful for those contributions from all sorts of contributors to the community we have eight open poll requests currently and have over the lifetime of the jenkins.io site close 2800 poll requests thanks to everyone thanks very very much and this concludes our meeting today