 recording is starting now so welcome everyone this is a developer meetup for the Jenkins project specifically focused on documentation and we're going to start off with Oleg's going to begin the presentation give us an overview introduction etc Gavin and I will be involved we'll show and tell some various things demos this is intentionally interactive if you have a question you're welcome to use the raise your hand icon you're also welcome to just unmute yourself and ask the question we don't mind this really should be intentionally interactive where we talk to each other now in order to verbally ask a question you will have to unmute yourself and we don't have so many people on the call so yeah let's just keep it relaxed this is my screen we do thanks okay so I'll start the presentation so by the way I shared this presentation in the six github chat and somebody could also be posted in the zoom chat if needed I guess it should be fine now right looks great absolutely okay yeah so thanks to everyone for joining our meetup so again we talk about documentation for Jenkins plugins specifically about just the presentation like user docs landing pages and also about change logs so yeah that's our agenda for meetup if you visit Jenkins online meetup first time we have a page on Jenkins online meetup where you wish you can join and follow our events we try to organize events more regularly and hopefully we'll have more events soon we have one event tentatively planned for December about Jenkins configuration as code we will likely do other presentations about pipeline so just this follow and join and we start a series of developer focused meetups so historically our meetups were rather for Jenkins users but we also wanted to have meetups for developers so the idea is basically everything about plugin maintenance some code dives development tools testing and shared ecosystem whatever so what we usually do at special group meetings so if somebody wants to present please do so we are looking for speakers and yeah the idea of these meetups is to have just more relaxed discussions between developers which I still recorded and yeah hopefully there is more discussions show and tell sessions then slides obviously if you invite me you will still get some lights but yeah the main idea is to have discussions yeah as Mark said today we have three speakers but yeah if you want to present something about your experience please don't hesitate to do so so we can adjust our discussion as we go so like at sick meetings yeah I will start from a quick introduction then Mark and Gavin will do demos and then we will also talk about change logs okay that's it so questions we already discussed so just move on either zoom chat or guitar or raise hand who has ever seen this page yeah Mark wait is a maintainer of git plugin and it's much appreciated and if you use Jenkins you may have seen this page and basically this is how Jenkins plugin pages used to look more less so we have more than 1500 plugins the most of them used to have documentation on wiki there were some additional markers etc attached but if you go to this page you see something like that so obviously there are some things to be improved but yeah a long time wiki used to be as a main source of plugin documentation now we also have her plugins to Jenkins IOT which was introduced as a part of Jenkins 2.0 effort so now you can find plugins here just for example you can get listing you can go to whatever random plugin and if everything goes fine you get the page with documentation here but again all this documentation is sourced from wiki so basically nothing changes specifically for this plugin so yeah this is how Jenkins plugin documentation used to work maybe had a lot of historical issues with it for example wiki is just hard to edit it's hard to add something yeah before 2018 we also had capture and I would say this capture was just terrible because I was able to pass it maybe in 20 percent time so something like that now it's gone but yeah still there is a lot of things going on this weekend oh like I am pleased to note that I finally submitted the request to delete the squatted git client plugin page that I had repeatedly tried to delete and that spammers had repeatedly brought back from the dead so okay I was living living the dream on that experience okay so yeah Jenkins wiki is basically based on Confluence as you may have seen this Confluence is self-hosted by Jenkins so we run it as a service we maintain it in the Jenkins infrastructure team thanks a lot for Oliver Nien and other contributors who helped to maintain that so yeah you can see this unstable ball on the hill but basically it stands not just on its own but thanks to the Jenkins infrastructure team which holds us from all sides preventing it from falling but yes historically we had a lot of issues this day this weekend uh one of the issues is just level for intra admin capacity so yeah we don't have so many contributors in infrastructure team this is something we're working on in the documentation special interest group as well by improving contributing guidelines by improving the documentation so that eventually we can have more contributors we also work on a user experience sorry okay let's go back to wiki actually I'm supposed to ground all about it so yeah Jenkins wiki user experience it's capture about all other things so yeah it's hard to really operate it it also causes a a speedbrain between information because you can have wiki you can have meet up with me for users it's hard to find to find actual documentation sometimes actual documentation is just missing and of course we have had some autoges and some performance issues there are some implementation details but yeah our wiki is really self-hosted so it's not in the Confluence cloud a class in cloud and yeah sometimes it's just slow and what it means if you're a plugin maintainer you release plugin you go and want to update change log and wiki is down so you send a message to infrastructure team chat hey I have a problem then you wait and probably you forget to put change log until somebody reminds you maybe a couple of months later so obviously it doesn't help then there are issues with security upgrades because Confluence as any other service also has some release cycles and it means that if you want to protect Jenkins users for example from the personal data being exposed or from just people are going and hacking the stuff and we need to regularly update and again it puts additional pressure on the Jenkins transaction team and a lot but in this is spam attacks so they think this is marked mentioned so historically Jenkins wiki was a destination for attackers because yeah if you have an account in Jenkins log you can go and edit any page without additional permissions without additional reviews there are some protected pages but yeah the most of pages are definitely not protected and yeah if you're like buying water heaters in Jakarta or something like that probably you would be interested in this spam attacks but for the most of users it's a major disruption and again people spend a lot of time just for cleaning up wiki, reversing changes, buying users and yeah that's why we had capture apparently it didn't help so yeah it's quite complicated. In October we actually had just another cottage and just another spam attack so maybe Mark has more content of what exactly was impacted but yeah we had a lot of pages I just missed the party but what you may have seen there was a tweet from Tyler about Jenkins wiki going to the read-only state the results a developer mailing list announcement so if you follow the Jenkins developer mailing list and we definitely recommend you to do so you can see that there is some comments so there is a lot of discussions so basically this was a trigger for the today's meeting and for all the work we present so stay tuned for that and here if you go to Jenkins wiki so I have a page open and you can see that there is a header there that wiki is still in the maintenance mode so basically the most of Jenkins contributors cannot edit wiki pages now we've got permissions for a number of users so that we can help with migration but that's it for the rest you should wiki directs you to the blog post so this is a blog post we sent out on October 21st so it's just four days since this announcement so in four days we basically updated all our guidelines thanks to Bevin we also created the first version of the exporter tool and we were able to offer a first version of this plug-in migration flow which we are presented today so yeah thanks a lot for everyone to everyone and yeah I think that's it for that any questions so far so so I guess one question I'm assuming that that the wiki is likely to remain read only indefinitely is that also your assumption Oleg or will there be someday in the future when it comes back so originally when I've seen this announcement my understanding was that we are going to reverse it back to the editable state but taking the success with migration tools with migration guidelines now I made my peace with the current situation so I am happy to accept the state that wiki is read only but yeah if somebody has concerns about it there is developer million please so just comment there and we can start from it so thank you certainly I don't think that it will be reverted unless there is a strong need to do so great okay any other questions okay then let's continue so yeah it's in read only state so what it means for users and for maintainers so firstly all user developer documentation which is still on wiki is not editable for plugin maintenance you can also cannot edit your documentation unless you migrate somewhere you cannot edit change logs because in most of plugins change logs and it's still posted on wiki and also you cannot update labels and labels were used historically for marking the plugins for adoption for putting plugin categories right now there are alternatives for that but you cannot longer use wiki as is so our default suggestion is migration and you have basically two destinations one destination is about plugin repositories on github so if you maintain a plugin you can just move for the documentation to your repository and if you just speak about genetic docs you can move to genkisayo so these are two main ways and both ways yeah both ways basically allow you to achieve documentation as code uh so documentation as code is just a concept which says that okay let's start our documentation along with all other product including code including build flows so now yeah we are used to start genkis files in a sm we also store maybe in definition it's an sm and the question is why don't we put our documentation there so i'll just show you an example okay now it exists i'm not sure probably i have some performance issues on my laptop surprisingly okay so yeah this is our genkis core repository so i just take it for example here you go to readme and here you can get readme inb so basically this is a file which is stored right inside the sm and which is displayed in github and it was one of the reasons of speedbrains because many plugins already had readme names to appear better on github and we can store better on genkisplagin website so yeah it was a quite difficult to find actual versions so what are good things about it you could put everything there you can also you can have additional pages with documentation i don't have them in this repository but you can just go to uh configuration as code for example plugin yeah configuration as code plugin so here you can see that in addition to the main landing page you can also have docs start right inside so here for example there is documentation developer documentation contributing guidelines which are a part of github metadata some historical documentation about plugins etc and there are also there is also feature documentation and you can see that this documentation is in both markdown and as edoc so depending on what's your preference you can use different format and hence you can put the entire documentation to github or what it needs you so firstly github can become a kind of front page for you because github involves its own ecosystem and it means that if your genkis developer then you will likely start from github repository now from whatever plugin site so by putting documentation there you can help your users and potential contributors to know more about the plugin and to see how to contribute etc as at the same time it's easy to contribute for others i'll show it later but basically you can edit this page right inside the web interface you can use markdown or i don't know as github and github offers a lot of features so yeah you can just click the landing button get that you can get preview in the web interface and everything would work also you can change your policies and this is where documentation as quote really comes into play because you can say that okay if you contribute for example a pull request you are expected to write documentation as a part of the pull request so it's not like something okay somebody creates a feature and then you ask that please update the wiki it may happen or not you as a plugin maintainer can set expectation that any feature has to be documented and it helps genkis users so that's the main idea and you can edit it you can review that so everything lets in the same time it also gives you a version in because when you release your plugin you get a tap tap in github so you also get a version of documentation which you released and you can point your people to version if they use different tools again it's not possible in genkis wiki per se yeah there is a history but it's hard to find what exactly the documentation for your version and the people can just edit it on the flight last but not least it's also about contributor recognition there is a story which i will be presenting about change logs but basically contributors to documentation just become general contributors of your repository so you can mention them in the change logs you can mention the documentation in change logs you can highlight these contributions and then finally motivate people to contribute more to your repositories so that's the main idea for that okay now let's take a look at the genkis io website so genkis io website is one of projects basically this is our landing so it's hard to assume that nobody's seen this on the call but just in case there is genkis io which is documented which is our portal which is our portal and the entire portal including all the documentation including all the listings sub projects etc it's documentation as cool so you can fully reproduce this site in your development environment you can hack it and basically i can show you development version which is just running my machine just in case so yeah it's a local machine i can edit it quickly and uh check changes so if you go to the repository you can find this site here so there is there are also contributing guidelines but basically what you can do you can just edit everything from the web interface as i said so for example let's say we want to contribute something uh yeah so here i can just click edit button and i can let's say i'll put hello world here or something like that uh and then i can preview changes and you can see that there is hello world here so all these pages on genkis io you can edit in this way and you don't need to put anything additional and after you do that you can just commit your change or submit a pull request i won't be doing so because i will pollute the repository because i have i will be submitting the main one but yeah that's the idea so you can quickly create the patches and moreover if you we talk about any documentation for example about pipeline plugins or something like that pipeline documentation is hosted on genkis io at the moment you can just go and as a user if you do not know where the page is located it's also not a problem because here it's a development thing so it takes a while but here if you just do not like this page you can click improve this page button and voila it just opens in web interface and as i presented you can just edit this page propose changes and submit it so that's how it works in this environment and genkis io is fully contributable if you want to suggest any changes you can do it from the repository and we have a decent documentation for different cases so there is contributing askydog in the landing you can see that there is a lot of topics like input and care guides for common cases if you want to change user documentation if you want to write a blog post you can just follow these guidelines and yeah this is the first way to do the documentation in genkis the most of things are being stored there as i said okay i guess i passed through this page and yeah what i wanted to say that this website was also introduced as a part of genkis to do zero so a lot of documentation has been already moved but not all over this documentation and we will have some example later today about how to move okay let's talk about plugins i've already shown you how plugins portal looks like so basically it's additional portal which is available from the genkis web interface and from the genkis website so it's basically a plugins where you can navigate the plugin documentation and this is a second major part of plugin documentation we offer because this website is referenced from genkis updates centers so plugin users who do the updates so they usually lend there to discover the changes this website takes data from genkis wiki and from our update sites so you can see that for plugin pages let's just take the random one i'm not sure what is this plugin basically just released with no documentation so i guess let's try something else okay so there's another plugin and this plugin already uses github as a source but you can see that there is some installation statistics information for dependencies links to java doc to github and lots a lot of documentation which is being sourced so this common experience for plugin users and this is what we were editing and one of the issues for us was how to migrate to the documentation in September 2019 we've got support of github as the plugin source so this is what we are presenting and let's see how to migrate this story actually is not new for genkis because we knew that the documentation as code is good a long ago and in 2016 we already had the jsoft project for migrating the documentation this project didn't succeed due to some reasons but we didn't forget about this idea there were some discussions there were some prototypes there are people who started moving the documentation manually but we really started getting traction in summer 2019 so one of genkis contributors zbenik he proposed a pull request we checked that github documentation support so basically he took over the list of ideas we had for jsoft and started implementing them i'm not sure whether zbenik is on the call today but yeah just huge shout out to him thanks a lot it helped us to move the story forward and yeah after some delays we finally started working on the plugin site updates in the background so if you think that we just implemented everything and for this after a week it was approved to redone the state it's not actually the story was already in our list we started this sub project in genkis documentation special interest group and in september we merged the pull request which added support for github documentation sources in our plugin site and after that this support was improved so by the time in october when a week went down we were confident that actually we can use this flow we already had some drop the balance for documentation migration so we were able to build the solution on the top of that okay i'm sure what's going on so what's going on with this the plugin migration one stories is support of github information as a source of documentation so yeah now we support readme pages and we publish readme pages right inside github but there is also other things we want to support like change logs plugin labels maintainer information so there is an epic in genkis github about that this epic is here and we keep it written on that you can see that there is a lot of green ticks but yeah there is still some stuff to do there then there is another epic to which we started for migrational plugin and genkis IO documentation so i guess it's the single epic there are not so many tasks for there because you basically need to create tasks so yeah there is an issue template for anyone who want to create a task for plugin migration but yeah this is a coordinated epic result documentation special interest group to keep this migration and we still have a lot of things to do for that oh like there's no requirement that i have to create a ticket in there i can i can certainly migrate a plugin to use the new the new system without ticket right i just just do the migration yeah there is no requirement so it's just for whatever matters because somebody may want to create a ticket for the clock or somebody just wants to create a new differently tickets for example for october first like we did before and actually a lot of plugin pages were migrated during october first so yeah you can use it but you will ultimately not require to create tickets okay and finally there is this blog post which fully describes how to migrate the things and how to enable the stuff so it's what mark and gavin will be presented in just a few minutes so it was me question there so so labels it's not working yet plugin label so yeah when i speak about labels there are for example if we go let's see i have configuration as code plugin open so here if you go to the root you can see that there are labels that configuration as code janky's october for the janky's configuration or something like that these labels could be made useful for janky's because for example if we go to the mail out plugin or to whatever you can see that there are some labels and here you can see that plugin has no labels because again we deprecated support of wiki and we didn't put labels right in site metadata we have a repository update center too so it's basically janky's between station for update center yeah it's the center that i'm mostly worried about that my scm tag will disappear when i migrate yeah right so here we have some so so it's it's long file so the yeah label definition set this yeah here we go so currently labels are being sourced on from this file daniel back has performed this migration maybe a couple of years ago so all information is being sourced from this page but if there is no metadata for example like for mail out plugin basically now mail out plugin has no categorization in the janky's update centers janky's installation wizard etc etc and it would be great to have support of github tags instead of labels so now if anybody wants to fix that you just go to this file and propose a pull request so so just for clarity that bobby that means that transitioning your plugin documentation from wiki to github won't sacrifice the labels did i understand correctly olag if they're already in this file that you're showing on screen they will continue there until some time when we transition the label support yeah right so for example get a trigger plugin one of the plugins maintained by bobby i believe it has a trigger label here so it will be displayed properly but i guess that the wiki integration is already there so what we see for mail out plugin so we can double check it when the plugin wiki yep our plugin site still has terrible SEO so it's not really easy to find it in google but you can find wiki easily and here you can see that there is old wiki page and this old wiki page i believe it includes labels somewhere uh at the bottom i think yeah i'm just not i'm not seeing between the bottom here so i am all labels yeah so that's why we don't have labels so probably wiki labels i still support it maybe not anyway i wouldn't bet on wiki label support to remain for a long time so yep my suggestion if anyone wants to fix labels just send me the pull request here and later we will see how we can use big hub topics for that because it could be more convenient for plugin maintainers so yeah so therefore such long question answer but it's one of things we still have in our backlog thank you okay yeah so current state so again wiki is in the real estate plugin documentation from big hub is fully supported so you can have read me as markdown as a ski dock they will be displayed you can also specify custom locations so that you as plugin maintainer can say that my wiki is stored my landing page is not on the read me indeed but somewhere in the documentation actually it was a pull request by bobby and maybe we have implemented it and by now we have more than 100 plugins which already moved to github so yeah it's a nice progress there there are some examples which i've already shown and if you want to see more examples one of the useful source of information is this side which we will present soon and you can see that there are some statuses so all green plugins if you go to a plugin site for example deep client you can see that there is documentation which is retrieved from github now these old screenshots with all pages with all the related links so if you have links to nice documentation they will be still displayed so with the current state you can migrate and the blog post describes how to migrate and i guess you will have presentation by mark and gavin so they will describe how to do that i already spent a lot of time so i'll just say thanks to all contributors i cannot list everyone on this slide because yeah we had dozens of contributors who helped this plugin migration uh and this documentation migration but yeah thanks a lot to zbenik who initiated this effort and pushed it forward thanks a lot to gavin for the migration tool and for all code reviews olivia had that's a lot of this deploying infrastructure because it also implied deploying services like plugin site or geek exporter and olivia helped us to unblock that mark also contributed tmda a lot and helped to coordinate it using the documentation seek and the team helped with the recent migrations and these progress starts so yeah there is a lot of contributors and again there is a hundreds of contributors who just helped remove the plugin documentation so thanks a lot to that it helped us to overcome the major infrastructure outage and probably we will be able to provide a great documentation for the users of jinx thanks olivia thank you so if there is no questions we will just proceed to these real demos yeah and i think gavin we've got you first on the list do you would you like to take take screen sharing let's see oh like i think that means you need to surrender the share okay i'm happy to do so where's my notes notes notes okay um oh yeah okay so i'm first screen share yeah there was a question from bobby about putting plugins for adoption uh but yeah i think we can discuss it after the presentation because yeah it's a bit uh also side question yeah so i'm just going to quickly cover the tool so this this tool started as a i wonder if i can do it and then it quickly became oh my god everyone's using it and i should make it work better so we uh it's uh started off as just a simple um you enter in a plugin name you and you hit convert and originally it just gave you markdown um olig asked very quickly for ascii doc so then we started to have the same thing where you wanted to do this you want you had a selector then that very quickly realized that for some plugins they have images so we can't really do this as a single box so then we added the markdown zip and ascii doc zip which i have already downloaded which will do the same thing but it actually includes images as a zip so you can actually do your fully export and then it quickly ballooned past there so now you can do the actual plugin id the actual confluence page id you can take any um confluence page or any wiki page uh i don't have any wiki pages open but you can put anything in there so you can just grab one at random put it in here and it'll it'll go find everything it needs to do and export it exactly the same way so this very quickly became a uh official tool it just started off as i wonder if i can do this and three hours later it was done um other than that uh yeah uh we also added a progress page which i think gavin gavin for me this was already miraculous just i think you you undersell how important it was what you did because i was dreading the the act of converting wiki markup into ascii doc because it's mind-numbingly boring and it doesn't require any real thought and you magically gave me something that produced output that was very usable so that that's it was great thank you for doing something i really like doing is i don't i know how much i love the command line and i know how much everyone else hates the command line so i like making tools that just wrap the command line for me um so one thing i will mention is while everything else in jenkins or the majority of other things in jenkins is a little java this is javascript so that might deter a couple uh contributions but for the most part i think we've actually hit pretty stable point um i was going to show i think i was supposed to show just uh a basic conversion so um the plan was i lost my notes but uh essentially you can do essentially any plugin in here so it doesn't really matter it should pull it should pull the uh the full markdown for you uh the of course the longer the the bigger the plugin documentation the longer this takes uh but it will run hopefully maybe if it doesn't it you picked a really big one but it certainly has run because i used it for git client plugin i used it for the git plugin and i know everyone is astonished i used it for the platform label or plugin as well that vitally crucial important plugin so i first prepared because i figured this will break because demos like that so this is just the output that the uh the zip gives me so i could i could do it offline later but essentially you take the uh anti-spammy markup formatter and it just pulled all the documentation from jenkins or from the wiki and it's supposed to make the screen a bit bigger oh i do that on this page because yeah for me it's fine but for those small screens it may be okay i have no idea how to do that so i don't know how to do it's not important uh okay i could i can do the other one though okay no that's all wrong anti markup not mark down thank you yeah sorry i can do that one though there we go now for those those like me who have have in inadequate eyesight thank you thank you yeah so again uh this is not the best formatted but it does function pretty well you can enter in your any plugin like i said uh and then if you go the same thing if you go to the actual oops that's actually a good one sure now we can't find the wiki any page any page you can do it well what you're highlighting now is one of the realities of the wiki is it's just not as high performance as the static generated sites are it it doesn't have really great response yeah um and mark will be showing that a little bit later anyways so i'm not too worried about it worried about my thing but yeah it will output the the files in both markdown and ascii and you can also do the zip file if you want it offline or you want zips or attachments that kind of thing and then last week uh we added a the migration doc which again i know we'll talk about later a little bit later but again this is just showing all the plugins all the ones that are either okay or to do are being pulled from update center so uh mailer specifically is okay so it's been migrated to the plugin site uh credentials has not been migrated yet and then some of the ones that are pr we've manually marked them as prs know they're in progress this is not an automatic process this is something we're still talking about how to do automatic but for now any of the pr ones are all manually marked and i think that's it for me on the actual app um i think mark was going to show actually how to do the full process thanks gavin yeah thanks very much yeah while we switch i would like to say thanks to pandoc team so pandoc is an open source tool which is designed for conversion of documentation so gavin did a great job to create a service and source for conversion but yeah under the hood we use another open source project which helped us a lot to get this thing done quickly so yeah it it was so easy with that tool you just say i have html i want marked down and it's like cool done yeah well we had to put flags started filter out some wiki styles etc because yeah wiki generates a terrible html yeah so yeah we did some investment in the flags but yeah basically it's pandoc on the hood yeah i noticed that the ascii doc the generated ascii doc had some artifacts left but they weren't disturbing much yeah right so that's what we have in our immigration guidelines you will have to clean up some artifacts and maybe a mark i will show it quick yeah right it it is it is an imperfect it's an imperfect translation for sure bobby but thankfully it's the beginning of a translation and a dramatic improvement over the oh copy and paste text trying to do that that slogging mind numbing work without the help of a translator oh yeah it wasn't much i needed to do to clean that up but almost worked out of the box it's awesome great absolutely do the zippy actually it'll do the images as well right yeah this this process at least for me has been an opportunity also to not just transform but also look at oh are there improvements i can make while i'm here and it's put the documentation maintenance right in my developer workflow so this is how you do a trans uh transition for a plugin i'm going to submit a poll request to the credentials plugin so first check check was on the migrator on the wiki exporter find one that says to do and you see the status up here that says oh we got less than 10 percent of the plugins converted so there are plenty of opportunity for things to do and some very high visibility plugins that actually already have documentation inside their github repository credentials is one like that so is scm api others as well so the migration process can be actually quite simple so the migration process starts with identify does this page use wiki-based documentation in this case it does and the the giveaway here is this plugin information block here which i'm on the plugin site but it's telling me to see the plugin site that's your hint this is coming from the wiki so then let's go to the how does the plugin site look oh okay is there useful information here well with this particular plugin this whole table is actually not terribly useful anymore because we've long ago gotten past version 2.1.16 on the credentials plugin we've a much bigger version number guess what the wiki is out of date but the source code is not out of date so here's the source code for the credentials plugin and if we look in its docs directory it's got a user guide a consumer guide and an implementation guide so what i think the plugin user should get is a link to the user guide so they need to link to this so all i need to do is capture the url of that page and now i'm going to go back to credentials plugins root level open up the palm and mark i think the user here is a api user not a jenkins user actually jesse that's a good that's a very good point but i think specifically in this case it really is a user let's let's double check because that's one that i think there is an i think there is an api consumer guide as well so what i see is the user adoc which talks about yeah okay maybe you're right maybe that is yeah well no see but when i read through this document it talks about things that i think are are vital to a user and has pictures for the user so my assumption was this is a better choice but you got a good point jesse that i may need to think carefully about what i'm what i'm showing to people but i think this thing really is user centered it talks about system scope and global scope and user scope now others certainly i think there are other plugins where it's really api documentation and that's probably not the thing we want to show on the plugin site but jesse would do you think that this is looking at what we see here is this a reasonable thing to present on the plugin the site hi yes yeah or you can just present this page which points to user guide or whatever i mean i'm going to use these pointers that's true i could just do the edit direct edit and put put another page which jumps into that and that was the that was the page here right which said i could jump to this one and then the then the then the reader of the plugin page could choose which one they want to do from there so either would be either would be fine let's go with for now let's go with short documentation and we'll have that discussion so we're going to take this one and let's go all the way up to the top level i just open up the palm xml file and i could do this in a fork on a local disk drive or i can do it here and i change notice that there is this line right here which is the url line in at the main level at the first level inside the palm file and i'm going to edit this file so click the edit icon now if i had not already forked this repository it would have forked for me so it's already copied into my fork and i can now go ahead here and see find that url again it was right there so i'm going to take that out it's not going to point to the wiki anymore it's going to point to master docs read me dot a doc submit my pull request so switch from wiki docs to github docs for plugins dot jankins dot io oh bless it how about let's use shorter words using okay that's fine now as a word of note here this i'm going to propose the file change i'm going to submit the pull request this change will not be visible until the maintainer accepts the pull request merges the pull request and does a release and that's that's just the nature of it we have to go all the way through the release process before it will be visible on plugins dot jankins dot io so let's create that pull request so this information has been pulled from jink sub date center so we generate special uh metadata file which has been consumed by plug inside in order to present other things so yeah that's why it takes so long so pull request ready and now of course this will run through the whole ci process on ci dot jankins dot i oh shame on me i should have given a better name than patch one forgive me but the it is that it is that simple now there are there are many different ways that plugins may do do documentation in some cases they may document the docs on the wiki may be better than the docs that are in the repository then your pull request should include a doc file you may choose to use the existing read me you might choose many different ways the same fundamental technique applies use the best docs you've got put them inside the repository either in read me or another location update the palm file submit the pull request release the plugin any questions so far oh i like that jesse that was awesome i i thank you very much your problem yeah thank you so maybe i'm not a question but just a comment there are two ways to specify the location of documentation so one way is to just put a link to your github repository to the root and such key is a plug inside we'll use github api to locate the read me page so github itself is able to locate read me from different locations and to display that it's one of the ways and then we will use github rest api in order to render for this page in html another way is to put a link to read me in markdown or a ski doc like mark presented so both both of these ways are fine and the majority of plugins now just puts documentation in the root of the repository because it's also the page which has been presented to visitors uh on github yeah it's a choice for any plugin linking it so if you want to set up a different you just do it by the way if you just link to tree slash master slash docs without specifying the read me dot a doc there will that still get parsed properly i do this and that one that one i don't know jesse it's a good question so the idea there was for the credentials the credentials plugin could it have linked straight into the docs directory right and then let it decode with file yeah without the filing right and and i don't know so it's a good question yeah right so now support either link to the repository or link to the file specifically you cannot link to a folder right now okay because the folders do not have presentation api well unless i'm messing up something this is the current behavior great so another oh go ahead yeah another thing to keep in mind that the documentation on plugin site will be displayed only for plugins using jenki's organization so if you host plugin in another organization we will not support github as a source at least in the current implementation because if anything goes wrong we have no access admin access to change the layout and whatever so when we were discussing options we decided not to enable it for other organizations yeah the most of the plugins are hosted with engine ci and this our preferred way of hosting nowadays thank you now oh like we had definitely wanted to cover release drafter we've got about seven or eight minutes left and i would prefer we go into release drafter because already just showing this piece i was reminded oh where's the changelog for these things and i really love release drafter did you want to get into release drafter for this session or do we want to do that at another time yeah we could but i thought it's for 90 minutes oh do oh we got time oh my mistake okay even better yeah i'm just checking because i was sure that i scheduled it for 90 minutes oh then let's let's go ahead that i feel much better that's good yeah my calendar actually says one hour so question to audience do we want to continue in a relaxed way or do we want to wrap up top in five minutes i'm going to continue me too i need to wrap up but you guys go ahead i i i know about release drafter so then let's probably finish it yeah my apologies i just scheduled it scheduled it to one hour in the meet up invitation we have information says 20 after for me so we got an hour 20 right so so i think i think i propose we go ahead at the casual plugins if people have to drop off i would much rather capture release drafter into this video that we can then refer people and have them watch the video later if they need to if their schedules won't allow them to stay that's okay gavin and i can stay here and even if it's just the three of us doing a recording that's still very valuable in my mind oh leg okay so you're done let's go ahead with our plan i guess we still wanted to talk a bit about jinxio right right so let's see so there were we had talked about this transition gavin was there another step that we wanted to show i love migration process we've seen how how easy it is to do that migration then we can migrate documentation actually from the wiki itself and i think you showed that in one example i've found others were there other things you wanted to show gavin so i didn't get a chance to actually show wiki link because i couldn't find one quickly enough um but also if you want to update the actual this page you can click on the icon on the top right a little good hub oh oh right so we can quickly do this it's a little bit i haven't done this in a while but uh if you scroll down there should be a prs dot yeah if somebody pulls js you went too far some of the ones i can show the immigration quickly if you hit t quickly was it too quickly here before if you get hit t to go file finder and then polls.js polls you need to type it yeah that one so if you're in here you can list this is the uh the repository name and the pull id so if you want yours to show up as pending then you can add it to this list otherwise you just wait so this is where i put the the fact that i have submitted the version column pull request thank you all right good i had missed that okay so if i want i want to record for other people okay i've submitted the credentials pull request i've submitted the one for version column all i do is go here submit a pr to this repository and that will properly show it in the table so that others know not to bother with that that plugin thank you although this is a completely optional step but yes right all like you said you wanted to show you you would be comfortable showing a conversion yeah why not so if you want to show a live demo great thank you well this demo isn't really prepared but we can do it okay this semester yes okay so we have some pages i just so you can see that there is a plugin developer documentation and although we started migrating this documentation three years ago wishing to do zero basically this process got stalled and some documentation hasn't been migrated and for example here i just opened a page and there is um rikin nscm plugin so if you go there you can see that it indicates that the development is in progress so basically there are some references whatever but the section itself is missing so we don't have anything to display here so what we could do just for the demo i found the wiki which says a cm plugin architecture or something and actually come then yeah so there is a name right in my cm plugin so there is some things i want to judge whether the content is up to date or not i'll just show the immigration so i take this page right now there is no images here so i will use the clinic export thing jinkins io jinkins wiki exporter so the tool which given presented and here i will use a ski dog because jinkins website works in a ski dog mode and here you just click convert so after some time we should get a ski dog which we could just put on the jinkins wiki sorry on jinkins io this is how it works for jinkins io but basically you can do the same for plugins you can just open them in your favorite IDE edit the documentation and just submit the pull request and if you export docs they export it in the format like we use for other plugins so basically you can just paste them into the right folder and the documentation okay so this is our documentation exported you can see that we put a remark with a clean a ski dog file so now markers now whatever i guess i was just lucky so here i have this page opened in visual studio code so basically this is the page we submit the data we show this is work and progress through flag so what i will do is i'll assume that we fixed that i will remove this flag and i will put the content so one of the things that you can see that based so one problem we have is pandoc that it breaks the lines at 80 symbols at this or some symbols we can adjust that but usually our recommendation is to align by dots so let's see what we've got i need to save the page at least okay i saved it and here if i just reload this page from Jenkins io yeah now we have content this markup is still here because we need to restart the development method it is not right on the flight by Jenkins io but yeah you just got the content in markdown and i would argue that even from where i begin it looks but in Jenkins io then in wiki well maybe except these flags but yeah that's what we've got so now yeah before the submission i won't be submitting public requests but yeah so here you can see that sorry can you set this can you set this to use one line per sentence for eski dot instead of pandoc doesn't support it right now there are other options but not one line per sentence a submitted feature request but it's not implemented yet so here you can see that we actually got some glitches for example there is a link to team foundation server plugin but due to whatever reason right now these links got lost i'm not sure why so it's probably glitching recent versions of exporter tool when we start cleaning up some references so basically we cleaned up too many of them so these links will need to be restored i will just show it to you so yeah i'm switching to line one line by sentence like thank you thank you yeah then here you can see some recursion because here we reference the plugin wiki but again it's not something we want to do instead of that here we would reference the plugin and here we actually would use jenkins wiki we can just say plugin tfs basically to be the same result as we had before because jenkins wiki is able to result this macro for plugins if you hit these keys then you would just need to have to put the full name so it's htps plugins jenkins io tfs plugin or something like that and we have a macro for this too somewhere for jenkins io yes for plugin wiki pages macros don't work so for plugin pages you have to write a full aski doc on full markdown without macros okay but whatever here we here you've got this page i've added additional link and yeah basically you can continue you can clean up this page you can clean up for example these references you can clean up sentences some other bits might be missing and if you want to see such mutations so basically there are two guidelines for you one guideline is for jenkins io so if you go to jenkins io github it works so here on the contributing page you can see specific guide which was created for moving documentation from jenkins wiki so just step by step guide how to do that and how to export how to submit pull requests so if you work on jenkins io pages you follow this guide for plugin documentation the process is really different but goodness is that we have another guide just second actually it could be great to link the blog post from this page as well but yeah so i'm just going to jenkins io blog and here we have too many blog posts recently yeah plugin documentation moving to docs so you can just refer to these blog posts for guidelines so there are some guidelines how to do immigration and how to update metadata what mark has presented and other things like pages etc we won't be touching that but yeah there is some stuff for that and here's a link for full guide for migrating plugin documentation in an automatic way with jenkins wiki exporter only if you do not like that yeah there is still one way document from this page so you can refer to these guidelines for the information what to do and what to review because we noted some potential pitfalls right inside our migration guideline okay so that's it with plugin immigration any questions or should we move to asky dog or sorry for the new doctor release drafter okay i think i think we're ready to move on we're thanks very much oleg yeah thank you too it was unplanned demo but okay at least we got some immigration next time we will be submitting a public request as well okay so yeah let's talk about change logs change logs actually is another initiative which we've started in june 2019 so let's have a go and yeah all my problem was with change logs because there are many places where you can find change logs in jenkins one of these places jenkins ior where we post change logs for jenkins wiki and lcs releases then we have jenkins wiki so many plugins post their change logs inside wiki pages the indifferent formats and it is obvious issues that it's not machine readable sometimes it's complicated to understand what's exactly there you cannot find it and actually there are many other ways to find to use change logs and jenkins plugin maintainers use all of these ways so yeah you can put change logs in your repository you can use github releases you can use external site some plugin vendors do that and some plugin maintainers just didn't try change logs on at all so yeah there are many ways and that's unfortunate for jenkins users because firstly they do not know where to find them and it's quite difficult so we had multiple options we could have said that all change logs should be on the plugin site or whatever but instead of that we decided to focus more on documentation as code for change log as well and right now we want to target two options one is change log and the in the repositories and another one is github releases so depending on your preferences you can use one of these ways and we still keep the jenkins io for plugin documentation so that's what the current documentation from jenkins documentation special interest group and one of the things yeah nobody really likes writing change logs plugin maintainers also sometimes we do not get releases of plugins for months just because people don't want to spend time on the change logs right now and they are basically it inputs velocity of jenkins as a project because we do not get enough insights of well maybe create obstacles for maintainers as users you have to go to commit history to understand what's staged what it takes so long etc and it would be great if change logs were automated so that maintainers do not spend time on that they spend time on deliver stuff for users and then a change logs could also be presented in a way which is helpful for users so you may have seen these change logs before because many plugins have already moved so this is basically what I present it's change logs which are being generated by release drafter as a part of github actions release drafter is a tool which allows to generate a change log and to submit the release drafter github releases with markdown describing this change log and then maintainers can decide one what they do with that next because they can put this change log for example to change log md or they can just release this change log as markdown release and this tool is actually available as mithub application so you can connect it to your repository quickly and as a part of our project there were a lot of contributors who actually contributed to release drafter because Gavin did some patches also team and Joseph Patterson they also contributed for jcast plugin but yeah this is what we started using for Jenkins project as a prototype and it works quite well so you can find it here basically it's not restricted to Jenkins you can use it in other project as well but yeah for Jenkins we started to adopt it on the organization scale because we decided that it would be cool if we unified across our all the repositories so how it works basically it reads your pull request and creates a change log based on pull request so there are other tools which operate on the commit level for Jenkins we discovered that it's quite complicated because there is a lot of commits being created and pull requests provide more insight so release drafter takes pull request titles it puts labels and generates a change log on based on this information and actually it's pretty flexible so you can configure it there is computational scope basically change logs are just markdown format that's what allows to move let's to change log can be if you need you can configure it right inside your repository but in Jenkins project instead of that we actually configured the global configuration because release drafter as a GitHub application it's based on ProBot it's a framework for GitHub applications and one of recent ProBot features well it was a ProBot plugin now it's a part of ProBot itself is configuration inheritance so basically it allows to deep merge some configurations and it's allowed to create a unified specification for change logs across the entire organization so if you go to GitHub repository so it's Jenkins GitHub so it's a storage for all kinds of metadata where you have code of conduct support security policies something like that here you can find that there is also metadata for release drafter not only metadata you actually have documentation describing how to use it how to configure that if you are plugin maintainer but also there is a configuration sample this configuration sample just finds everything how we configure change logs so here for example you can see default name templates so in Jenkins we mostly use digit version for plugin so we enabled it by default we have some categories for example new feature bug fixes which again configured here on the global level we have a template and we have replacers so for example if you want to reference a jira ticket in the pull request or see or if you want to use some common acronyms like custom or package or Jenkins file run here just for example you can use replacers in order to configure this feature and then you generate this change log so allow probably open yep oh like is it okay if I ask a question at this point so in using release drafter I think I had to define in my repository the labels it didn't seem like the labels were inherited from the parent that the label definitions were inherited should they have been inherited so label definitions is a problem in github because in github historically there is no way to manage labels as the configuration is called I suggested that the support few weeks ago but again it only offers default labels it doesn't offer labels for for historically created projects so basically it had no particular value for us to use it in that way but we could there are other alternatives for example if you go to configuration is called again here you can discover another pro bono petitions settings which basically does some configuration and here you can see that it configures labels and there is even my pull request my comment to move it to the shared github so we could have done configuration is called label for configuration is called for labels and other things in this way but it's not implemented yet and basically each maintainer has to enable labels and configure them on the on his own right now but a good news is that default labels created by github are here so for example when you create new repository there are labels like enhancement or bug and you can see them there so out of the box you already get some labels and yeah later we can improve once we evolve Jenkins ecosystem because here we can manage labels across the entire organization but it requires some scripting for example in github actions but technically we can do it now okay so there's there's a potential in the future for automation the the technique I had to use was actually okay of creating my own labels in the repositories I have that are existing that aren't new repositories thanks exactly so we can improve it later so here I'm just showing you a change look in real life so for this plugin the release was relatively recently and there was no changes so here you can just see released versions for the non-released versions let's take configuration as code plugin yeah you can see that there is some one request nourished by team so here if you click you can see that there is a draft so this is a incoming change look which has been automatically generated which is not additionally handcrafted so it's what has been generated the thing that this change look is only visible to maintainers I created a feeful to github to have a support of publicly visible change log drafts but it's not implemented and I'm not sure whether it will be implemented but I think that it would be great improvement but right now it's only for means users still have to go to commit history to see what's in coming so yeah these change logs are generated automatically and cool thing about that that configuration inside the repository is just like what it is yeah it's here it's just like that so we just few lines because everything comes from global and this the configuration you can see in the most of the projects which already adopted release router so this global configuration basically helps maintenance to spend a lot of time you just need to specify tag template because maybe in a release plugin by default injects artifact ID before the version so we cannot automate that and yeah we could have automated that if this drafter supported it but the switch is not available right now so there is no template for repository name so we could use a repository name apply regress or whatever other major but right now you just have to set what the field which is probably not reveal and you get all these change logs running before which release okay so yeah I will just skip this page so what are you doing it to do if you want to use a release drafter in your plugin so firstly you need to release enable release drafter there are multiple ways you can go to this release drafter page which just describes everything step by step if you need it but yeah this is just a quick summary so you can release enable it as a github application basically you just go to this side and if you have admin permission in the repository you can just say that I want to enable it so what's going on okay so you just open this page so you can see that there is a number of organizations I go to Jenkins I need to enter my password and here you can see that there is configuration so as I'm Jenkins admin so basically I can enable the release drafter everywhere but you as a common user will likely be able to enable it only for your repositories where you're admin and by default we now get you can't admin permissions to plugin engineers within their repository so here you can see that there is 127 repositories which adopted the release drafter so it looks like a big number but it's working a 5% adoption across the plugin ecosystem so we definitely have something to improve I'm very happy to see the Chuck Norris plugin that has released drafter yeah it's our most important plugin yeah you can see that there is a lot of plugins that are also almost all developer tools which is used to reduce drafter because for development tools we had even more difficulties with maintaining changelogs and now yeah it's just click a button and you get this changelog so yeah there is a lot of plugins. Hey I was I was rigorous in maintaining the Git plugin changelogs seriously and the release drafter changelogs are dramatically better dramatically better they look better they're more navigable there are so many things that they improve because of that layout the hyperlinks are more useful and also throughout if you go to the very top Oleg uh and you do the watch drop down uh the page you're on now there's a watch button all right so one of the cool things about release drafter is you can now watch for releases only and every time a release happens and a new tag happens it'll actually send you a notification probably not a good idea for Oleg who gets a thousand and two hundred notifications a day but for me who gets a lot less it's really nice to be able to watch releases on your favorite plugins and then this is hooked up to that which was a lot nicer than your update center is suddenly getting a new update and you're like what changed yeah moreover if you so if you're not subscribed to this repository you have this uh uh banner so everybody who's visiting your children's loads will be automatically offered to subscribe to update okay so let's quickly finish that so yeah if you don't have admin permissions you can ask us by just creating a ticket and then we will like to just give you admin permissions because we are fixing it up slowly across the organization and the third way is to actually use github actions because yeah in some cases we had to add support of github actions for example for gradle plugin because there is a bug in recent version in the current version of release drafter github application so instead of that for example in github action we use uh in gradle plugin we use github actions to generate and you can see that there is a fork for ginkv3 release drafter which basically fixes a few bugs we hit and here you can see that the same change logs have been actually generated by github actions so now is there a is there a benefit to using github actions is there something that that would that would benefit me i'd never never consider using github actions instead yeah so there are two benefits one benefit that you get execution log because with github application you don't get one so here you can go to run actions and you can see that there is log and whatever because it executes and if something fails you can you can investigate the failure there another benefit that basically it runs on github actions so you can understand when the job runs or not when you use github application you basically rely on the release drafter service to execute everything correctly and if there is otage or whatever the change log may not be generated so here it's more deterministic is there any chance we're going to add this to the default plugin groovy file for ci drinkins as well we could so basically we could release drafter right inside jinkins pipeline we don't do that because yeah we had some issues with jinkins stability over past months but technically we could run it and then we will have jinkins port submitting release drafts so we could do that so now jinkins bot submits us build statuses like these ones and yeah we can teach it to submit release drafts as well so yeah we can we don't do it right now because it would also consume github rate limit which is a quite limited resource yeah but yeah technically we could do that okay so let's finish the slide back then yeah you can also add labels so after enabling your repository you will start getting drafts but you still need to categorize normal release changes to get a fancy change log if you don't like labels you can just disable them by verifying the configuration and then you will have no categories but it's totally up to you and you can then you will need to update the documentation to perform the change logs so what we usually do in our plugins now so if you go to for example the role strategy plugin here you can see badges so something like yitter chart and also a badges one with badges links you to change log and then you just navigate here so they did value of these badges that these pages are accessible on the plugin site as well so here they are so even if you don't support change log listing here yet you can see that there is badges right away so yeah so we recommend to update plugin documentation so that users can find these change logs and later we will be injecting additional support for the plugin site and after that you will have to release the plugin because you need to attach the change logs to something and then you will need so we had an example Mark would you mind if I use the plugin just for the demo no no you're welcome to please yeah so here we can see a draft of version 4.1.0 by the way congrats with 4.0 release for gift plugin yeah and we have change log so this change log is basically just a draft generated based on pull request titles so yeah you as a maintainer you can improve them before merging but ultimately you can you may need to do some fixes so for example here let's say we don't so here quotes we don't like them we can put something like that in markdown so just copy it into the change log and then preview it appears as a term or you can add additional hyperlinks you can put additional data and we also recommend to put summaries if you want to highlight something so for example here you put hello world or something like that after that we can also edit label so by default it will inject labels although there are some bugs but here for example we can create label we just shouldn't publish this change log in such way but yeah you can do that and you should do that because otherwise release won't be associated with a particular release tag created by maybe and then you can just publish this fine-tuned change log and then all users who are subscribed to release notifications will get it so basically even before they see that in the update centers they get notifications with a change log summary so they can see what exactly was released okay and yeah you just publish it and after that you get this change log basically generated and available to your users again drafts are not publicly visible i'm not sure well hopefully we will change it at least for release drafter but yeah that's the current state of affairs in github so some highlights almost all development tools at least all development tools which we touch they use to this drafter now for change logs so plugin forms and other common tools you use the plugin maintainer they already switched to release drafter i'll have a few minutes left so probably i'll just show it so yeah this is a plugin form and plugin form when you see it here you can see that there are change logs which are also generated using release drafter so same as before and these tools these change logs are really essential because yeah i'll just take dependabot i'm not sure because dependabot is one of the tools it actually is actually able to pull change logs so here's a better example because there is just commit history let's take a bill of materials maybe we have something there okay a bomb gdk2 from version 1.3 to version 1.4 and here in the public list we have change logs which are surprised generated by release drafter so there is some other logs between tools which basically help you as a maintainer to understand what changes is outgoing for work so yeah there are advantages and that code in dependabot is really complicated because there's no standard for so release notes is cool but then sometimes they have a change log option and it's pulled from like 14 different sources depending on what it's there so yeah release notes are very supported for dependabot it's really nice yeah so maybe we will do something like that for jinx plugin site maybe we'll just take dependabot core because it's open source well who knows but yeah it's yet to be seen so yeah now we have more than 100 plugins which already moved to release drafter so far so good we did receive some pull requests to change the default templates to add additional labels but generally it gets adopted well and you can contribute to these default resources it's just pull request on github and we have several pull requests several contributors from jinx projects in the release drafter ecosystem yeah thanks gavin my case i just contributed the issues and somebody fixed this recently so but yeah it's still good so yeah 127 repositories as on the morning the uncounting and actually we have some plans so first the integration with plugin site so showing the release change logs on the plugin site if my wish list is to also show it in jinx web UI so if you go to plugin manager you can also see the change logs there so that as a user you can easily access this data again it's not clear how to do it without github API limit so maybe you will have to cache this information plugin site somehow yet to be seen and yeah then it's also great would be great to have aggregated change logs because for example if you use bloatian if you use pipeline i guess it's a challenge sometimes to understand what exactly was fixed and in which exactly component so for bloatian it's a bit better now because it's a mono repo but yeah for pipeline it's hard to find the things so by aggregating these change logs we would be able to easily understand what exactly changes for plugin users when they do multi updates and yeah they will be like a lot of changes in change log formats in addition to that we are also working in in the jinx core change log automation i'm just not mentioning anything there because yeah it's a separate story so if anybody is interested yeah there is there are links and there is documentation right inside our github repository and you can contact us using seed channels and like github or mailing list so if you have any questions just let us know so any questions before we start wrapping up okay so yeah this meeting went over time a bit but again it's first time we do a developer meetup so yeah things to improve so yeah jenki's needs you and actually we need contributions because yeah there will be a lot of changes and the new renk haltoberfest we received hundreds of contributions and dozens of them go towards documentation towards date immigration but there is still a lot of things to do and we seek help from contributors so yeah you could help just by talking to us and the documentation seat because we seek feedback about the documentation you can help us with plugin immigration as given shown today we still have more than 1,000 plugins to migrate so definitely there is a place for contributions then you can migrate jenki's site or documentation like i presented today you can help use migration tools like jenki's weak exporter in it's on github so if you want to improve it for example but data conversion or whatever just contribute a pull request or if you want to use it in another project for what it was because there are other confidence users who want to migrate then we have plugin site and for everything we will also appreciate the reviews and copy editing if you go to the documentation special interest group page you will be able to find things to put requests which are waiting for reviews if you're a plugin maintainer yeah we recommend to move the documentation to github it doesn't mean that you'll go become reliant on github because it's one of the fears right now because documentation is just in it so it's portable between other sources and yeah you still pull the controller it's not like github pages it's not like github weekly you have full controlling set your repository you can follow documentation as code practices and it's pretty good same for changelogs you can move either to github releases or to changelog mde and it's something you could do and if you're all over there you can just add fun things like for example pages, repertopics, links to channels like to github so that your users can reach out to you contributing documentation and whatever as a member of documentation seek we really encourage you to improve your documentation for both users and contributors so that in the future we can facilitate contributions to the plugins and if you have any interest to meet us yeah we will be at the DevOps world Jenkins world there is Hackfest on December 2nd and at this Hackfest we already have some documentation related projects so we can just sit together and have something that is contributor summit on December 3rd and yeah I guess there will be a prospect of for Jenkins weekly outage where we will also talk how we could do better next time and the term and I guess there will be other topics and of course community booth so if you just go to the conference you can meet me, Mark and Garen Ayogevan at the Jenkins world, maybe next time but yeah you can meet the Jenkins contributors there ask any questions about documentation about whatever you will be there to help and yeah of course there are discount codes for those who contribute and who participate in meetups so don't forget to use them. Contracts, yeah we have documentation special interest group page and basically you can go there and find out more information about the special interest group, about the projects we are working on, you can see that we in documentation have basically our project there and you can also find connection links so there is mailing list, there is chat and there is a link to meetings so you can follow these resources in order to join our meetings, they usually don't try this but a bit earlier than this meetup and you can join and any contributions will be much appreciated. Okay I guess that's it from me, are there any questions? Wish we haven't covered yet? No, people have been answering all the things in that. So any additional comments anything else? Yeah thank you Oleg, thanks very much and thanks to the community for the contributions that we're receiving, that's wonderful, thank you thank you. Yeah thanks to all so yeah we had a question from Bobby about plugin ownership, we could take it off line or we can briefly discuss it now on the record. I'm gonna have to go so I'm gonna go thank you. So I guess we just closed down because yeah there is a developer at least discussion of all the topic and right now the situation isn't a bit pleasant there so yeah again thanks everyone and yep. Thank you everyone, I'll end the recording and end the