 it's great to have you all here okay so let's start our presentation so my name is Barbara and I'm a technical writer I work for the chemo project I've been with chemo for like over a year right now in my spare time I love tray running and of course going into some more details about documentation and documentation tools and this is Tom yeah hi I'm Tom and I've been with the project as well for the last year and a half and the open source project chemo I also like to develop some musical ideas in my free time but today we're not going to talk about that we're going to focus on documentation called the open source all the rage so let's have a quick look of what's in this presentation for you what topics are we going to talk about so we are going first to tell you a little bit of this is just a brief overview of documenting for the open source world and we are going to show you how we do things in our project in project chemo and then we'll have a look at the house and why is why should you do it and why is it beneficial to treat your docs as code and then we are going to have a look at us the technical writers as developers but not your regular developers but information developers and if it works and how does it work let me spoil that a little bit it does work and do show you how so let's start with this law that all of you should and probably know here so the open source software all the rage right now just a quick check how many of you guys do actually work in open source projects raise your hands please okay cool so many things we are going to talk about here might not be new to you but I guess it's cool to hear that some people are as other people are having the same experiences or similar experiences as you do and so when people talk about the open source I think that it's safe to assume that mostly the association is open source the code of the software right but what about the documentation what if you took what if you take all of the principles and the ideas behind open source so the openness the collaboration and the fact that anybody can contribute to that code what if you take these principles and apply them to that documentation of the project and as you've proven us there are many of you who already work in open source project so this might not be something new to you but believe me there are still projects and companies which have their documentation separate separate from their code and relationships between groups of people that work on the documentation and the groups of people that work on the code are not these of openness and collaboration but they resemble sometimes I'd say these gang relationships between rival gangs in West Side Story and so we worked in such an environment before Kima started as an open source project and and when we were given the opportunity to move our documentation closer to the code and to the developers and ourselves a little bit closer to the development process and to being real developers we jumped on this idea without much hesitation and our company I don't know if they realize that but they helped us a little bit in making that push because on our employment papers at SAP because this is an SAP project we are called the information developers so that gave us a little bit of inspiration and I mentioned the project name quite a few times already let me show you here in bigger font so it's Kima and it sounds foreign right Spanish Italian maybe foreign so I'm going to spill the beans and tell you that Kima is a Greek name and in Greek Kima is a wave and this name was chosen for our project because we wanted to be on the same boat and yes it's a pun it's a terrible one but stick with me as some other major players in that whole area so other projects that we look up to and that we work with that share this Martyn Greek name scheme I'm gonna just name two of them one of them is Kubernetes which in Greek is a captain and the other one I want to mention is Istio which in Greek is a sale so what does a technical writer do when he or she when they want to prepare themselves for the inevitable come of the coming of the open source and we thought to ourselves well we have to prepare some guidelines and there of course that as you probably know there are these customary documents in open source projects like the projects main read me the contributing guidelines but these are mostly and the code of conduct but these are mostly cult oriented right so what about the documentation from the very beginning we knew that we wanted to allow people from the outside to contribute to our documentation base we didn't only want this project to be focused on code when it comes to external contributions and when I say external I mean not only external as complete strangers so to say but also external as in not only our core development team from within the company and when you're preparing for that inevitable thing to come you have to prepare some some guidelines don't we all love them right but we knowing that people from all around the world and from all around our company are going to be able to read those guidelines we thought to ourselves well nobody's going to read them if they're long and if they're convoluted so we made sure we made them clear concise and to the point and we created a completely separate as you can see repository within our project to store all of these guidelines and these documents that help people contribute to our project and we also render them on our website just like the rest of our documentation is it and as you can see many areas are covered from the entire content strategy which is described here to smaller things like diagrams everybody has to know what color is they should use right or how we do screenshots how we release notes etc so if anybody wants to jump and help us or show us that being something needs documenting they can check the guidelines and get a better idea of where the matters fit in also on the technical front I'm going to switch to the next slide one slide further and we worked on two things so the first one was the entire look and feel of our website which we think of as the main entry point when it comes to consuming our documentation so we had it of course a dedicated development team that worked on the website but we weren't passive we bounced ideas back and forth we tested prototypes we made sure that the user experience when it comes to the website is as documentation friendly as possible and we are quite pleased with the results I hope you are going to visit our project website after the presentation and then comes the more technical aspect of publishing the documentation so this is basically the workflow and when it comes to from the very conception of a document to having it visible as our website published as our website so we write our documentation markdown which is no stranger to the most of you probably it's a very easy thing to do everybody can learn and in just a matter of minutes then we push our documentation to to our github project where we designed a very well organized structure so that we are sure that everybody knows where the documentation should go there are no no asterisks or hidden paths there then after you create a pull request with your documentation which is of course another typical github thing the rest hop happens automatically as we like to say because our static site generator and Gatsby is notified about the fact that hey there are changes in the documentation please build a new version of our website and so it does but first before you merge the pull request you are given the opportunity to review your changes in the context of the entire website how do your changes influence the look of the website how does it look with all the styling the CSS whatever you can check if everything looks the way you expected expected to look and then when you are ready you click merge right sounds easy I hope it is if you decide to contribute Barbara you shall take over okay so Tom has just told you a little bit about the Kima story so how we work in open source why we decided to do it and what our documentation looks like also and how we created so how it's all happening like on the let's say the technical side so behind me there is the the Kima website so the dogs that you see when you when you go to Kima and I would like to add some more things about why we do it why do we pay so much attention to the dogs right so imagine you are looking for a solution that helps you to expand or extend your applications in a really easy way so between your job and looking at pictures of funny cats you encounter Kima right so you go in and the first thing you see is well documentation because you want to install it you want to play with it right so that's why you go to dogs and in a like let's say more standard approach the documentation comes with a solution so the company buys the solution and then there is the documentation that you use right to start it to work with it to enjoy it so here is it this is a little bit on the other way around so you first go into dogs and then you play with the solution let's say so that's why we pay so much attention to it so our documentation not only consists of the manuals let's say but we had also our Kima blog where you can find out more about what we are doing we have our community that Tommy just mentioned a just a while ago right and then we've got our roadmap that you can also visit to see what is there in the future for us so you have you you see that there are a lot of details there that make you happy about it and it's about the website encouraging you to just you know start working with the project so you can be either like oh yes I want to go further with that or like I'm gonna look for something more right so that's why we pay a lot of attention to it okay so that's the let's say first part of our journey through technical writing world and here you learn a little bit about Kima as I said and a little bit of documentation in our project let's go to technical writers as information information developers so I don't know how many of you work with technical writers anybody anybody yes some of you are technical writers I know that and yeah but some people technically when they hear like okay technical writer who is a technical writer okay that's the guy who will write something that is technical maybe he like is an editor or somebody similar to that but in our words technical writers are the people who look for the input take the input from a developer and then make beautiful dogs out of it right so just that's what does with that's what we are looking for every day and yeah but in our company as some mentioned we are called information developers and that's what we want to explore today so how are technical writers the developers in what way how does the code does the documentation as code approach helps us is it beneficial at all to technical writers and the teams so let's start from docs is called approach in Kima it is very close so we can see that it's like the docs and code are the very two layers of the same Kima cake let's say and why is that so first of all documentation is kept in the same place as we mentioned as the code so we keep it in the GitHub repository we have our beautiful documentation structure in there and we just maintain it and make sure that it's always up to date so that's the first thing the second thing is we write for developers so we are like more leaning towards the code than the for example UI experience right so that's the that's the difference also that's why we wanted to keep our dogs even closer to the code and thirdly you cannot really get to Kima without the code without the code but without the documentation because when you you can of course like refrain and just not go to the website but it's always there for you it's in the Kima console is in GitHub so it's like ready part of our project right so that's our Kima cake with docs and code and now let's explore a little bit the docs is called approach how is it utilized so it all starts with this bright idea so we've got our requirements for our feature let's say we have this new Kima component that's our feature right developers think hard about the future implementation and and that and that there are the people that want to you know contribute to the documentation as well so we've got our code on one side and documentation on on on the other side and of course there obviously a lot of people that like to write documentation like who enjoys writing documentation that's perfect that's I really really really appreciate that but usually developers are like I don't really enjoy that maybe there are some other people that could help us with that and these are our technical writers right so these are the people that help you we work on that yeah so we work on the on the side of documentation so to like sum it up a bit we've got our code we've got documentation and we would like to follow the same process right so the journey starts but it's not that complicated as this right it's really not complicated it's not like take your ring tomorrow or anything like that it all goes to one poor request so for those who are familiar with give-up and I think that there are a lot of you we create our documentation in the same way as developers create code so if there is a technical writer working on his or her set of content just putting it into poor request and then of course there are further stages that the poor request has to go through but it's like the same way right so after we've got our poor request with our content there is this part that we call the review because we have to ensure quality right so we go through the review part which is the same for the code and for the documentation so we still follow the same rules so if a technical writer writes something there is always another technical writer that checks it if the developers fancy some writing and wants to write some documentation and contribute to what we already have then the technical writer is notified about that and can also review this read me file or whatever markdown file is there for him right so that's our review additionally we've got our pipelines that we use to run tests against the poor request so it's again the same process for code and for documentation we've got for example projects that help us to figure out if there are links that are dead links and we can just right away correct them fix them so that there is nothing nothing wrong with our dogs right and here is our quality sign so after creation review we can say okay fine we can merge it right now so that's the process and so the key let's say takeaway right now is like we follow really really the same process and we follow the same guidelines and now I would like to show you also the poor request that we have so this is the sample one so you can see here that technical writers and developers cooperate on this poor request from the very point of creation until it's tested and merged right so we put some small tests of the bottom there's some discussion going on in between some finger pointing some yeah so this is how it looks like it's the same and now let's explore the outcome the benefits that it has for us as technical rights and can technical writers really be somehow treated on the same level as developers and how can they contribute as information developers right so first of all there is this context of creating documentation being close to the code this in turn fosters the team effort put in our work as technical writers and as developers right so we work as a team on the other hand technical writers are not only that just the people that write we have many hats so it's not really just about the writing and of course we contribute to the community as working hand in hand with with the developers right so starting with the context as technical writers we really dive deeper into the context let's say on the same level as developers and keeping the code so close to our documentation really helps helps us to do so right so we are always in the loop and this in turn also affects our work as team members there are developers excited to meet the writer so it really it really helps us to be on the same team as the developers there are some other solutions I've also been working with the team of writers so we were like on this content island a little bit further away from the devs which of course can be also working well I'm not saying that it's not but in our in our situation it's better to keep the to us so we can work together we can be there as technical writers from the planning to the release of the feature right so we are going through the same processes with the same people and cooperating right so this also facilitates the mutual understanding between the team members and that's what Tom will tell you more about let me take over the clicker and to yes move to the next thing okay so mutual understanding and Barbara mentioned these two models the one that we have in our project and the old one the other one so to say so you can have either a I mean we work as either a separate documentation team of people who are dedicated to working on this one thing or we can just blend in with the devs and with Kima being an open source project and going open source we decided that it's time to end this division and it's stopped it's time to stop seeing the right the developers as cavemen who don't see any use for anybody who doesn't write code and it's it's a good time to stop being embarrassed with everything and the developers right when it comes to our documentation so when we are at the center of the development cycle we see the features as they are conceptualized as they are tested as their first POC's some features of course get discarded and we can be sad with the teams and with the developers I mean and it doesn't really take that long to you know us to understand the developers and the developers to understand us being in the very at the very center of the development cycles cycle we can teach the developers a lot and show them that we are with a lot as team members for example remember these guidelines that we created thinking about external contributions well one of the major group of external contributors for us when it comes to the documentation is the group of the developers instead of doing everything for them more often than not we are able to educate them and to let them know hey you're adding this to this then maybe you should write about it in our documentation here look at the guidelines look at the dog structure makes sense right and after a few times the devs are able to that's wind that's not a bomb shelter alarm or anything don't worry and so after a few times the devs they start to write dogs on their own and there's much that's less for to do for us on our own and we you know become one so to say we also have the opportunity to help to coach them a little bit when it comes to their language skills we can help them develop their simplified English skills because you know writing in simplified English which is very good for technical documentation is not something that everybody's born with you have to train that you have to work on that we had to work on that a lot and also our project which is mostly not a natively English speaking team all of us can benefit from polishing up the English a little bit and we try to help the devs with that so they see the benefits they see that we are not only these pesky spell checkers and these grammar Nazis that we are not always asking questions and demanding that they explain things to us we can also share our knowledge our expertise with them but in a little bit of a different field so there's this mutual understanding that's based on the fact that we both mean that us the technical writers and the devs that we are both experts just in different fields and we try to instill the passion for having clear documentation for the things they develop and it is a great thing to have because sometimes after talking to us the developers decide for example that maybe it's a good idea to expand on the error messaging because you know you don't want something like this to happen in your project in your product because who's going to understand that right and we are basically the closest thing they get to an end user without getting out of the office without getting out of the project we don't really know that much about the details of the implementation so when they talk with us about the different things that they implement we can give them feedback that it's much closer to real world rather than pure review that happens on pull requests so that's one thing that's great and when you are in the team and you are working with documentation that is this close to cult you're sitting among the developers among these cavemen that I mentioned before of course that's a joke and we don't think that's our caveman is that on record yes okay cool and so then you are tempted to hey can I do a little bit more maybe can I save the world not really maybe can I can I do some quality assurance why not I mean we are down and dirty with the product as Barbara mentioned our product is our project is developer oriented our documentation is developer oriented so in our docs you see that the common line interface is a first-class citizen we don't really document the user interface because you know the user interface is basically a nice wrapper for what going what's going on under the hood so and with knowledge like this we are often treated a little bit different by the devs and they just say hey look I have this new feature it's great here's the pull request deploy Kima and try it on your own okay I will tell you a bit about it in like two hours try to figure it out now figure it out on your own basing from the task description and basing on the chain changes in files that happened and what are we left to do we just do it right we just fire the thing up we try to figure out how it's supposed to work and how it's supposed not to work and we often as the person that is that is a little bit closer to the end user we are often able to identify some things that are maybe not the way they should be and sometimes to notice bugs and we are you know with our limited development experience both of us happen to catch a bug or two and even fix it in the course we are very proud of ourselves and we don't really think that is going to happen ever again but it's a memory we cherish and the last thing that is really easy to do and you are at the very center of the development cycle is community management and from our experience we can say we both can say that the devs you know they like working with code dogs now community why do we have to do that isn't there a dedicated community person well no and behold there is it's us I mean we like doing that we like talking to people we like right we like writing in English so it's not a problem for us when there are people interested in our project who come to our slack which we invite you to there will be a link at the very end of the presentation to our project slack and these people do what they don't want to hang out and you know share memes but we'd love that maybe we should create a dedicated mean channel I believe there is one there is one okay so I'm not there come on and instead they ask questions they want to know things they share their problems and they want these problems to be solved so what we can do with our knowledge with us being more of an information developer rather than just simply a technical writer we have enough enough knowledge to simple these problems which are often simple to solve these problems which are which are often quite simple because people are often having the most problems when they are starting out with our project and we are able to tell them what to do we are able to answer their questions or at least point them into the direction in the direction of the of where the documentation that would will help them solve the problem is because we have this kind of a bird's-eye view on everything we kind of know what's going on in the code in more or less of a detail and we have a really good overview of where all of the documentation is so it's fun to help people and the devs are happy because they can focus on code so there's that and the final aspect I mean the second one which is the final aspect of the community management thing is the release notes which are of course a very important in our opinion way to communicate with the community that is around the project well everybody wants to know what's in this new 1.8 release right and you can do it in a very stiff and boring way with just a simple enumeration of new features or bugs fix or whatever or you can do it our way where we swore that we are not going to be as stiff and as boring as we could so we are trying to dance this thin line between puns and really information every time we create a release notes we take turns so it's never the same style but the idea behind release notes in our project is this we decided that it is up to the development teams to choose the features that they want to be highlighted on their own so we asked them we remind them please kindly let us know what features you want to have in the release notes by this and this date of course they go past it tremendously but you know that's all another thing but when we have these summaries and these highlights what we do is we create an introduction and that is more fun a little bit funny and a little bit more less stiff I shall say and we summarize everything that's new in the new release and then we proceed with the part and that's a little bit more technical and describes the features that the developers give us that they want highlighted in more technical detail and that's it when you when it comes to us being parts of the team I think it's a great thing to have I mean as being close to the team yes absolutely I I also second that okay so I believe that's it for a second part of our presentation and this is our short summary and some takeaways for you so you know now how the docs is called approach more or less works in our project and that it actually works for us and what are the benefits of it so first of all dogs released with features make the dogs always up to date and also it shortens the development development the documentation back because sometimes when you work with a totally separate tool it's like yes we're going to develop it right now meaning the features and then the documentation will be like just a little bit later right and here it's just like okay the features have to be accompanied by documentation right away so it's also like a help for us because we don't get our documentation task piling up right and then dogs are processed and stored in the same terms as code that makes them the same class citizens we use the same processes to create dogs and code we work in context and the process itself is simplified rather than if we have like a separate tool that requires different completely different style of work gathering input from the developers and then putting it into some into a separate tool then waiting then building and all of that so here it's simplified and it also as I said and we mentioned forces the second car writer and developer mutual understanding so one thing more is that they work on the same team so it really also means a lot to the technical writers meaning they know more about the topic and also for the developers to have the technical writers on their team to help them with the content and also to act as sort of information developers for them so these are our benefits and also we encourage you to become a chemo contributor if you want to that is our website so chemo project IO that's our website our naked dogs are under under dogs basically in our you have a story and you can also have a look at the website source code so you can then know how we do it what is the process of creating the website and the tools that we use and of course we encourage you to contact us we have our dedicated chemo slack channel so just if you feel like it just contribute and if enough of you show up maybe we will create a meme channel that's actually I meant yes I would love to be okay so thank you guys a lot yeah for listening to our presentation that's it but we welcome questions that we are trying to basically answer and we have some yeah and if you are shy we brought some t-shirts and some Lego figurines that are related to our projects so that's a bonus if you have a question but if you have a question you're shy then this is a good motivation to ask a question okay go ahead please meeting points where those documentation and actually code are coming out of the same files like there are frameworks that generate code documentation from code live or well of course these things are there but what I'm really interested is how to smoothly integrate that so that the nice documentation which is written as documentation and these automatic generated stuff how did they do each other so that you don't really see anymore which which part are out of generated which part of memory generated so that that it to create one flow like like this other generation where you do an annotation in the code like what would I think of as well tooling that for instance makes some some kind of a documentation out of configuration files if they follow up some styles or if you maybe with some intermistic language where you tell how to make this configuration file a doc file a documentation file and this then into the manual created stuff I guess that could repeat the question okay so for the recording I think that to sum up your question is how to integrate things that are in code and make them automatically into documentation and how to integrate that with manual created documentation correct so that looks like one thing that is together okay so see that's that's a thing that we don't really do we do not have any in our code we have this approach where the documentation is basically always manually written but the whole styling process and publishing process this is automated so there is not really when it comes to the core product there is not a place which is flagged like hey whenever this changes please generate a new document we don't do that so everything you see on our website is manually written by us or the developers developers however there is one place that barbells works with that has this approach yes that's our chemo CLI because we have our own CLI so you can use to work with chemo so for the developers it's just easier to install it and work with it and the documentation for the CLI is based on what we have in the code however all the flags and commands they are generated from the code and we are just right now starting on integrating it with the manuals that we have so probably I will have like a good answer to your question in I know next year next year next time we're here hopefully okay so we are just starting to work on that because right now we have all the all the documentation from the code generated into markdown files and then obviously treated as well as normal markdown files they can't be then rendered on the website but these are separate ones and we want to add to the list of these commands that are basically auto generated we want to add the whole documentation of the CLI so that's the that's the process that we are going to figure out I think in one two months yes manually written yeah it doesn't make sense when you've got like a lot of like a list of commands so basically that's why we for a CLI we use the auto generated documentation but we want to integrate it with more CLI dedicated dogs so it's going to happen still it's like with you know analog versus digital I mean there's always a group of people who will say that whatever the case is whatever the application analog is always better so I guess I believe in that when it comes to the documentation so I'm an advocate of human written documentation it's always in my opinion better than automatically generated one even if it takes more work probably not my feeling was that there are parts where it just is someone taking part just like these commands okay we'll move on to another question so maybe you can always give out this swag after our presentation okay so will we come to us after we we're done we'll give you the t-shirt and other bonuses okay so we have a second question here fourth row mr. with this car yes basically this is the same yes so sorry I have to repeat the question for the recording so do you recommend having a separate repository for the documentation because of the different processes that there are when it comes to the docs and the code actually it is the same repository as most of the code so the entire project is structured so that so that there are some parts of the code in different repositories but the the meat and potatoes are in the same place where the dogs are it's just a different directory and it's just basically when you have automatic testing it's up to choosing what tests run on what pull requests and I don't think that there is really a recommendation but in our case we wanted to have as we mentioned in presentation the documentation as close to the code and basically on the same rights so it is a natural decision for us to put the documentation in the exactly same repository as the main portion of the code however we pull the content for the website from different repositories because community for example comes from a different repository yeah so the whole community tab which was there basically comes from a different repository so we have both but when it comes to the like really content for the chemo apps and the project itself the manuals and stuff it comes from on the repository exactly so sorry you have to raise your hands again hi you mentioned you write the documentation while the developer develops the code how do you interact do you do you agree on certain specifics before the developer starts developing the code so you can write a documentation that fits mm-hmm is there any any process you go through to make sure that the documentation then fits to the code that's maybe not yet written sure repeat the question okay are there any processes that we have that ensure that the documentation and the code are on the same page so to say when we start to write a documentation for a code that is just being developed would you like to answer today no and so it's all we talk basically yeah we talk a lot we try try to be in the loop as Barbara mentioned so depending on the developer because the flow of the implementation it differs from person to person from task to task so what we do we actively participate in planning sessions so we know what features are going to be implemented in a given release cycle so we have an overview of what's going to come with that feature what's what it's going to do and then it's up to us and the developer to talk it out and decide to whether we can start documenting the feature before it's even conceived or whether we should wait a bit because let's see we know that the developer is going to code a desk but is the desk going to be this high or this low or is the desk going to be black or brown so then we say okay so we don't hold that yet so let's wait let's say two or three days and give you some time to clear out the details of the implementation and once yep yes and that's why we are parts of the team that that's being a part of the team makes it very easy because we are you know brothers in arms or sisters in arms yeah and we would love that that would be awesome okay okay Barbara choose the next question I believe at the back yep yep I think we should repeat the question for for the recording so the question is if we employ any reusable content in our documentation okay which answer so right now we don't I believe we we just write everything like manually and and we don't actually employ any reuse strategies right now but well I think that it's it's an open question but it depends how you what do you understand as reuse strategy because we do not reuse definitions of objects of custom resources whatever because these are this has to be they have to be written for specific cases but I think where the reuse comes in is the fact that we have document templates so there are some document types that that are generic enough to be for the templates to carry enough information that it's just basically take the template and fill in some details and then you have ready to go document no no no we don't have that we don't have a flag that's let's say let's use table and this given idea of a table or a concept or definition can be inserted wherever we want with a given mark or something no we don't do that in this project so it's not like for example if you have documentation in a content management system like for example Excel soft then it allows you to have like this reuse pool and then you can just pull out from it and have it like in multiple pages so we don't have it now yeah okay great awesome yeah okay last question I believe it was given to us like this sacrificial lamb and we loved it we loved it's puppy eyes and no I mean it was the decision of the of the team that worked on the website that was look at me yes you know the guy and and it was fast enough agile enough it was prone to changes that were that had to be made in order to suit our needs it was flexible enough I say that they chose it and it works great we don't really have any problems with yeah with that and we also have a group of people that really know the ins and outs of God's be so they can work it yeah do we have time for any more questions yeah I don't know if you have many more swag but we cannot we have five minutes so we can we can take one or two questions dependent on yeah because we've got like only five t-shirts but yeah curious when you so you mentioned you use markdown source for all of your documents yeah here what was the motivation for choosing markdown as the format for the doc it's easy to use it's close enough okay cool so it's easy enough who of you works with markdown yeah so can you all who thinks markdown is easy to use who of you thinks of that markdown is easy to use yes so you see it's a very it's a very visual markdown language yeah brain for it when it comes to formatting and it's basically it's foolproof I'd say there there's a very low learning curve so we thought that if we are open to contributions we shouldn't really employ any systems that are difficult to use for people from the outside you don't really have to have a doctorate in using github on open source projects to see our dogs and see hey this formatting is screwed up I'd like to create a pull request and fix it for you because I just noticed it sitting on the toilet and looking through your website right so you can do that in a matter of minutes if you google markdown basics so we have very few custom implementations but you don't really have to know about them to write documents for our website I think that it's yeah it's also easy to source right so basically you can render it on the website I believe that since in our company there are like a lot of different documentation teams and they work with different solutions so we work using markdown github people use CMS so it's really different people use confluence and and basically it's really also easy for them for example to take markdown and put it in the CMS so I think that's also the you know multiple ways you can use it yeah do you think that using markdown brings drive-by contributions to your project do you get a lot of drive-by contributions to your dogs so yeah the contributions there could always be more we would love people to to come and contribute to our dogs more even people from within our company we are still a you know year and a half with this many great open source projects out in the wild we're still a young and relatively small project but we're happy with the number of contributions and what makes us even happier is the fact that when people finally decide to contribute they don't really have a lot of problems with getting to what they need to do I guess I'm gonna rephrase it so do you have people who contribute continually the people the same people who contribute keep contributing or is it people who will do like little one-off things yeah like it's wrong mm-hmm at this point we don't really have like constant contributors we like these drive-by contributions as you said are more a thing right now and I believe you had a question right okay yeah sure okay I think that's gonna be because people oh yeah let's wrap it up thank you very much