 Am I on? On? Oh yes. Hi. Welcome. I know it's Friday after lunch. I'm trying to stay awake myself I apologize if my voice is a little bit going out to a karaoke bar the evening before you give a talk is not a good idea so Thank you for having me so my name is Mikey and I am Having trouble with my clicker So I'm a technical writer for Red Hat I've been a technical writer for almost seven years now. I document OpenStack before that I documented JBoss I've also been involved with Feed Henry. I am a scrum master Don't hold it against me. There are advantages in that in my ever-decreasing spare time I run the European chapter I guess of Write the Docs, which is a documentation community I talk about docs in developer conferences like this one and I also organize Django girls workshops like we did here in the beginning of the week I also coach Developers and open source projects on documentation. So we actually had a help desk with a couple of my esteemed colleagues On Wednesday where we into we had people coming in and getting some advice on their open source project documentation And yeah, so I don't sleep very much I'm based in Burno check Republic. So it kind of makes it easier to get around So why am I here? Why did they put me in this gigantic room? and Brought me all the way over here to your Python because apparently some people think that documentation is important And it's important to me. Obviously. It's my job. Otherwise, you know, if I didn't care I wouldn't be doing this for a living But it also if you don't do this for a living, you know, our users are the ones who have to use your software, right? so They care about it because it helps them get a better experience it, you know, the people who create the software It also helps them because they get to Be able to showcase what the software can do and for the organizations for the communities so It used to be and it still is to varying degrees, right? So like Documentation has kind of been a thing that happens to other people Or it just kind of happens magically But thankfully This thing is a bit finicky So thankfully there's been a shift over the last years last few years where people understand that Your content that accompanies your software is basically a part of the whole package, right? So you have your software you create it you test it you support you document it and then you deliver it to your users So how do we help the success of a software project, right? First of all, how many people here write documentation for a living or as a you know in a project or something like that on a regular basis? Hey, it's not bad cool. I was wondering where everybody was So There's that's kind of there's a lot of different ways of breaking down How things can help how documentation to help you, but mainly it's you know, you want to improve the user experience So, you know content any kind of content could be your user guide could be a read me It could be UI strings or an error message, right? All of these things are Pros that accompanies your code, right? So the so not only that but you want to create A portable and adoptable workflow for how to actually create and use your product, right? So if you have internal processes in your in your project or in your company You want to be able to train people that you've never met in person, right? So it's you know the easiest thing to do is to sit down with someone and be like, okay This is how you use this, you know the software or this library or whatever it is, right? But you want to be able to create something scalable and to create something scalable in today's world You got to be able to give people some text, right? You mean giving a presentation, you know going to events like, you know doing some I don't know consulting in a company or something like that though. Those are great But like you want to be able to reach the people that you can't do in person So join the Docs Club, how do we get there? I've broken this thing down to the three sort of Themes that from my experience Make it like you can do a lot with not a whole lot of initial investment Like you can do this effectively, right? You don't have to just you know, if you're a developer You don't have to you know retrain as a technical writer and you know spend tons and tons of time learning So there's a lot of things that you can do pretty effectively So the first thing that I'm going to talk about is content strategy and content strategy is actually like a marketing web development term that's being slowly applied to the field of technical documentation and It's basically about asking the right questions before You document something, right? So I'm gonna not be original here I'm just gonna use the 5w's because that's what everybody knows, you know It's a very sort of global way of grouping it So the first thing I want to know is who are my readers, right? So, you know, if we're talking about things like personas, do I I'm not I'm referring to end-users developers administrators Business analysts, whatever, right? You can also divide the users according to skill level So is this project is the software going to be used by absolute beginners? Is this something that? You know a very very specialized API used by people who are already Very very experienced, you know, like am I talking about uber nerds and you know, who are the people that I'm? Writing this content to right. So this is also an indication of who your software users are right. So You can also do you can also break down the users according to geo You know some, you know, you talk you talk comparing like the Americas versus Europe versus Asia-Pacific, you know different people need different things And so the next question is what do they want to know, right? So for example if I'm writing Django girls tutorial, right? I Don't really need to give them the entire history of Python and Django and like just get them into deep dive, right? You want to get them the information just enough information that they need, right? So if they want to get started learning about About Django via the Django girls tutorial what sort of information do they need? So I will create a tutorial with a very very slimmed down version To be able to be digested more easily, right? So if I'm documenting let's say a very complicated deployment like of You know service-based architecture or something like OpenStack or you know So there's a different level of information that they need So and then the next question is when do they need it, right? So when I say when it's not necessarily like What time of day or you know, whatever, but it's in the if you look at the Lifecycle of the usage of your of your software, right? So if we're talking about Django girls as an example I'm an absolute beginner. I've never used this thing before, right? Or if let's say we had somebody in the help desk that came in and had a documentation structured At cross purposes, right? So you want to if people come into your project for the first time you want to give them a bit of background About what this project is for what they can use it. Why would they want to use it, right? So this is the beginning and then when they could start when they get started and then they start using The software then you can give them more common tasks Let's say like if I want to do some administration some configuration, you know And then later on if they get into trouble, right? Like what sort of when do they get to your content? When are they going to need this? And then the next question is of course where so when I was talking about things like error messages, right error messages are basically just another form of content, right and a well phrased and informative error message is Better than a 10 or 100 page troubleshooting guide, right? because if I can give the information right when the problem occurs then I've saved the user a lot of frustration and I've made their user experience better, right? So if you're having if you're creating a command line tool, you know, and you just want to go man this You know, this is right there in the terminal. So this is aware And also, you know people naturally after they've tried everything, right? They'll naturally review to Google, right? So how do I make? My content available and accessible online for example or or do I want to do it in a PDF for some reason? But I mean PDFs are still important so These are the I'm just kind of throwing a lot of questions because I'm not actually going to answer all of them because there's so many different ways of looking at it so And then the last question is why right like why do I care? Why are you showing this content to me? How is it going to fix my problem? I was having this discussion a couple of days ago With someone who said that bad documentation is just as bad as no documentation and I actually think this is of course my opinion that Bad documentation is worse Then no documentation because if I'm a user and I got into a problem I need to find something in the documentation. There is no documentation, right? This sucks right like but I realized that this sucks within like maybe a few minutes and then if there is a bunch of Documentation and it's wrong that I'm gonna read the whole thing and it's gonna take me like I don't know 10 20 15 minutes, and then I'm gonna get even more frustrated. So Why am I writing this like what am I solving here? Right? I mean why so for example if we're writing What was it an installation guide you want to get your all of your prerequisites? You want to find out the information and then if you deploy it Then you need to know where you can go next as well, right? So This is the kind of question that actually puts all the previous questions To a test and sometimes it uncovers a different problem, right? So if I have to write a big big document that for troubleshooting and for FAQ and it turns out that I'm just really Documenting bugs Maybe we want to consider fixing the bugs so that we don't have to just stick it in the release notes Right, so this is a tricky one, but it's very very important. So now I'm gonna give a couple of examples I wish I could give more examples, but there's just like so many and I could just sit and talk about this all day So the first example I want to talk about is user or role-based Breakdown of content and this is the GNOME help. You'll know it And what I love about it is the first thing that you see when you go into the GNOME help help that know project org Other than the fact that you see a bug or I see a bug. Can anybody see this bug? I wonder if you can see this bug Thank you very much. So, I don't know. I just I was looking for it and I'm like, hey, wait a minute. There's a problem So you have users administrators and theoretically you're supposed to have developers here, right? So I need to file an issue for that So the first thing that you see is GNOME asks you who are you? I should put a Alice in Wonderland Caterpillar meme here. So who are you, right? And then if I'm a user I click on users and then I go to a browsable sort of categorized Library okay, and According to what the thing what type of activities I'm doing in the desktop, right? So it gives me the information that I am most likely to look for as as a user And if I'm an administrator then these are basically the administrator only or the administrator specific Documents that I need so I don't need to worry about how to you know configure my email or install a new Software through the software collections or something like that like this is the thing that a will confuse users And if I throw all that other stuff in there the administrators would be like just just give me what I need Right and then you have the developers. We have the development center You have the APIs you have the platform demos So this is a really nice example of how to use persona based or role-based Information delivery So the arch Linux wiki. I'm assuming most people here know what it is What I like about showing it as an example is that everybody raves about this wiki And I've been hearing about this since I started going to events And at first glance it looks like a mess right and I'm thinking to myself Why right because I mean I don't use arch Linux and you know, I'm still like Try I'm in the Linux user in training, but So I'm looking at this thing I'm going why does everybody love this so much and then I realize the only thing they care about is this Right because and then I realized this by the time that I get as an arch Linux user by the time I get to this wiki I've already tried everything I could possibly think of myself right and I've tried Google whatever so I go to this thing already knowing what I want more or less or at least have a few keywords in mind and a wiki doesn't have to be Browseable right a wiki base is not meant to be hierarchically structured, right? So it's pretty flat And anyone who you know tries to manage their documentation for a more broad Open source project like I know fedora kitty, you know those kind of things It's tricky right when you're trying to address a more broad audience, but I only care about this I want to find what I want and I want to find it fast Yeah, so now I'm going to give an example of Structure and conciseness So one of the things that we're working on this is this I love red hat because we always have a very kind of humoristic self-reflection attitude So in open stack all our documentation is available publicly on the customer portal So if you see here, it starts off like okay I have like every you know every link here is a different guide And then you have the release notes, but then you know You're starting to get a little bit more complicated a little bit messy and you go like I don't know One two three four five like seven upgrading guides, and then the getting started section is so long I couldn't screen capture it And I'm like where where do I go right? So this is actually something that we're working on So we are at the moment as we speak, you know Reviewing everything we have right so it doesn't really matter if you're just starting with your project with your software project Or if you've been doing this for a very long time, right? There's always something to improve and there's always there's it's never too late to also look back and Improve what you have and we're actually to fix this We don't have to change any of the content of the guides, right? all we have to do is look at What these guides are talking about how do we break them down and just sort of dump everything in one pot and Reorganize it so we're working on it, and if you want to follow it you can see when the next version comes out at some point so the second thing I want to talk about and is I Wanted to use doc ops, but somebody trademarked it so this be it so DevOps for docs is a concept that We've been kind of kicking around the documentation community for a little while and some of the things are Some of these practices have been around for a very long time Some of them are just starting to sort of come to light, but the basic concept of it is that we're borrowing Terms and practices methodologies from the engineering world and applying them to documentation, right? so if like beef, you know Long gone are the days of a word processor to a printed PDF, right? Like we don't do that anymore if we can help it because it's a lot. It's very restricting, right? So The first thing I want to talk about is the unified tool chain So for example, we've had a lot of people come up to us and they helped us and go like, you know Which tools or which markup language is which publication tools should I use and the first thing I ask is What's your language? What's your technology, right? And like so if it's Python if it's Ruby if it's whatever right so like in order to make the most out of the documentation tooling we turn to the engineers we turn to the developers and we see what do you use? You know, how do we integrate the documentation authoring and publication into? The development cycle right so it makes it easier it makes it easier because you can just add a documentation string in The code and then you can auto dock it right or you can Java dock it or whatever it is you want There's so many tools out there that can just hook into your code and extract some documentation, you know and not just that I mean you have like GitHub uses GitHub to document GitHub like there's there's a there's a talk about it and write the docs Portland So to be able to kind of dog food your own Engineering tools, so also things like issue tracking, you know to be able to get a documentation type issue in your bugzilla Right or or JIRA or whatever it is just using the same platform to track Documentation tasks Saves a lot, you know because I mean it's otherwise people will just like I'll send them an email I'll see if you can review it or whatever so what we do at hat we have a lot of Every product has whatever Tracking platform for issues and we have our own documentation projects for some of them And so our engineers or our users they can open issues for us, right? So I mean for open source projects is a lot easier because most of the time It's all in the same place, but I mean in the enterprise world. It's a really big deal so And then we have things like continuous integration so every time you you know make a commit and Rebuild the library it checks for you know, you can check for broken links. You can check for you know sanity all these different things And iterative authoring like I said used to be a scrum master I'm probably never going to stop being a scrum master entirely So it's always going to kind of accompany me wherever it is I go and I just I hate looking at a giant pile of tasks I'd rather break things down into more manageable chunks and this is also another thing is if you have iterations in your Coding then integrate your documentation into that. So like I mean if whether you're working like Sprint plus one or or making a documentation of a feature actually a requirement to deliver this feature, right? I mean, I know that I've been hearing more and more about projects that Really do implement peer review For doc for the content as well as the code not that many yet But hopefully I will talk about this in a little bit if you can increase the engagement of the community in the project That things like that can actually help right? So this is I'm talking more of like more infrastructure and the tooling that they can be involved in there So content curation or as we call you some call it sharpening your axe so When I went to I did a sorry I did a documentation sprint with Nick out next OS And I went into their documentation library, which basically they had like four guides each guide was like one giant file XML and Like with it was just it was it was scary for me and I've been writing and authoring an XML for like, you know six years So I can't imagine like if somebody wants to contribute something to it Then they'll just you know, they'll just drop the computer and run away screaming So like things like so what we did is I broke down this gigantic XML file into topics and files And I just organize it in a hierarchical way and so if people want to contribute then the source files were curated in a way That's more modular right? So if you go to the next OS documentation on github then you can see the four main guides Have that kind of structure so you can move things around if you add new features if you want to break it down It's a lot more manageable And you have automation which I love Because I'm lazy So laziness is the mother of automation And when I say automation in a documentation context, I don't just mean like things like continuous deployment Which is more critical for the bigger sort of projects You know, if you just have a wiki base or get hub read me then you have continuous deployment. Congratulations But things like automated testing for documentation and not just for code examples Because code examples can be tested with whatever it is that tests your code, right? So it's the same thing but you have tools like Hemingway and Emender and also a Sublime plug-in From what I hear about more and more tools like that They won't fix your grammar for you, but they'll tell you how what you need to fix, right? So because we deal with pros and not with code There isn't it isn't as straightforward as you know success fail built right so if I write a paragraph and it's really clumsy and long and has a lot of like it's in concise and ambiguous Then you have all sorts of tools And I'm gonna post with the slides. I'm gonna post a bunch of links Because just I want to get through a lot of things So you have a lot of tools that can report things like you view, you know, this sentence has a passive voice or If I write the phrase in order to You know some tools will tell you you don't have to use three words to say something you say with one word Which is good because a you're not wearing your readers out by making them You know, it's it's it's not a novel right like you don't want to you know The point is to it's a functional it's functional English right like so it needs to serve a purpose and The subtitle of this talk is keep it simple present and present simple is the sort of golden standard of technical documentation So you can do this, you know this window opens, you know, it's all very very simple And the reason for that is that your what you're talking about is more important than You know impressive writing Expressions right so it's not an expressive language So these kind of tools I would love to see more collaboration and more innovation around it So if you can just Google The tools are follow the links that I will post. I think they're really cool And they could be integrated into a lot of different existing infrastructures Okay, so and so the third thing that I want to talk about is basically the community engagement and the contribution engagement and how do we make how do we make how do we help the documentation improve by Engaging the people that we work with to care right so in this context We have seen that a lot of many times, you know, the people who Work on these open source projects. You're like, yeah, you know, I wrote this code, but I don't have time to write documentation, but you know, how do I so what one of the things that I do and Some of my contemporaries do as well is you know, we go and we try to Show that a it doesn't have to be such a tedious time investment So even just a little bit of forethought Things like asking the right questions or just thinking a little bit about the infrastructure and how you're integrating into the development cycle Right, so all these different things Outreach efforts Is one of the things that we do that we can do So I'm just gonna give a few examples of the type of activities that you can do in order to Increase the engagement from a community or from a project from your contributors. Of course, this is not Conclusive and there is lots and lots of things that you can do, but these are kind of the things that I've Personally and from talking to people I've seen That had a good impact. So Of course You're welcome to experiment and explore So the contribution guidelines is things like when you want Somebody to contribute to documentation. How do they do it, right? So just like when you have How to contribute to the code of a project just if you invest a little bit of time in figuring out an Optimal contribution workflow or some sort of effective contribution workflow for your project. It's gonna be very helpful down the line So just as an example We wrote this and like No, I think it took us less than half a day like maybe like a few hours at most And it's like a one wiki page on how to contribute to the documentation. It has like, you know What do I need to do? Right? So here are the steps that I need to take in order to contribute to the documentation They didn't have this and now they do and I hope it helps, you know, I mean, I it does I mean, I've seen I've been talking to them a little bit over the last few months but So this type of investment that can be just a few hours and you don't even have to collaborate on it, right? Like if you just figured out how to Contribute or change something in the documentation of a project write it down You know and then it'll help others and then you won't have to keep doing it yourself, right? So this is kind of this is kind of a Preemptive delegation, I guess or in scalability. So another good trick is to use templates and the template is worth a thousand words I've seen here one of the examples that I love that's used a lot is the read-a-docs read-me template And I keep hearing about it's like, oh, this is a really like I would literally go This is a nice me read me. Where'd you get the template? It'd be like here, you know So even if you don't necessarily have a template if you could just point out a topic or a file for One of your pieces of documentation that you think looks good and that the project agrees like so last year if I thought we were working on a Plone read me and They basically are using that as a template for all of their other read-me's So all we needed to do is to get something once looking right and then you can use it You can reuse it and use it as a basis later So things like collaboration and training, you know all these engagement So these are things that are obviously easier to do when you are in person So what we do things like Sprints and hack fests for documentation So this is from last year's Europe. I thought we did a Django girls doc sprint and at This is dev conf they did a workshop about dev assistant and Jenkins for docs So these are all activities and that's from flock to fedora So these are all activities that are done in developer conferences, right? so going into the sort of more broad general open-source tech community and really Helping to educate and coach and train and mentor it it helps. I mean, I've I don't know We had a help desk for it was supposed to be three hours and ended up being four hours because we had so many people come in and you know I love the fact that that the open-source community is so open to receive these things, but you know if if if the writers and developers we can all get together and Cross-train and share the knowledge. So these are good examples of how to do it. So even if you are not a writer We you have Sort of the newer generation of documentation conferences So I mean some people probably might remember the Society of Technical Communication the SDC Which is kind of like your grandfather's conference? and But you have conferences like write the docs like open help and you get sort of pop-up or ad hoc documentation conferences as a part of a bigger conference So open up and write the docs are like the two most popular Documentation communities so open help is more focused on sprints and write the docs is more about we have conferences we have meet-ups as well and The people who come to these events are not just writers. In fact, we probably have Like maybe a third of our attendees that write the docs are writers and then the rest is you know split up between Split up between, you know developers to sediments community managers project managers. We got you know marketing people like you have everybody coming into the same space and talking about content, right, so We have a conference coming up next month in Prague open help has the next conference in September. It's in Cincinnati and so these are exactly the kind of places that I would feel at home as a writer and You know Anybody can enjoy because the developers can learn about how a writer thinks, you know and these You know the the the project managers can learn how to integrate between the different roles and everybody wants to improve the documentation in order to help the success and the adoption of the project, right? because I mean everything is so we have such a Huge amount of information nowadays and there are so many project Projects so many technologies. How are you gonna make it stand out, right? So if the first thing that I see is your github read me You better make it friendly, you know like you don't want to you don't want to lose me so early And the read me is documentation as well So whether you are a squirrel a badger a beetroot or a capybara, you know, everybody can care about content and you can care about it in your own way based on your own role and You don't have to do it alone because there's oh, you know Hopefully, there's always gonna be someone from a different role that you can collaborate with So, yeah Questions. Thank you and things We've got like seven minutes for questions. So if anyone wants to ask, please keep your hand, right? I'm always I'm also gonna be hanging out afterwards So, hi, thank you very much for this great talk Given that you're a scrum master I was wondering if you have like iteration on your documentation as well So if you bring for example the PO to your to you basically and make them Prove or just prove your documentation Okay, so what you're asking is do we develop documentation and use the same stages as software development? Yeah, in a sense. So if you if you do sprints on documentation, so will your product owner? Be at the review meeting and say well I don't really like this kind of documentation on the specific feature and you go to another iteration Okay, so that's that's a good question. I didn't actually focus on that so much because It's more I think Applicable to the the enterprise world rather than the the sort of small project world But for example at Red Hat, we have content strategists Who basically act as product owners for the documentation and just like you have In a release meeting or release planning you have the you know the engineering lead the QA lead the support Design productization etc. So now you have someone from documentation also in this mix, right? And when we plan the content strategy for the next release we collaborate with all of those people and we come up with a plan And then the content strategist will pass it on to a Documentation program manager who's kind of like a tech lead, right? So it'd be like the engineering team lead and they would distribute the work and break it down into iterations or tasks now specifically for iterations So what we'll do is because the doc the requirements the tasks come up to us already pretty much thought out So we have a basis however Many times we are faced with oh you need to document this feature and then by the time we get to document it Throughout the development of the feature it changed pretty drastically So we have to do a lot of research So before I actually go to document something I will normally either contact the engineers who developed it or the QA Engineers who tested it to see I look at test plans. I look at specs. I look at blog posts So I just had to document something and I'm like, oh, how am I gonna do this? And then the engineers like I wrote a blog post about it and I'm like, thank you You know so these kind of things help write blog posts and then send them to your writers because we love that And then what we'll do is we have So this is I'm talking for most of the companies that I've worked for so far I've used a similar process. So we'll draft it draft the content send it out for What we call a tech review or an SME review and then we'll send it out to a peer review with other writers So you kind of have like a two-step Authentication on your docs before they get published So I hope that answers your question anyone else Do you do for public-facing documentation? Well, do we what for for general documentation? Do you do stuff like a B testing to see if one way of doing it works better with the Clients or people use the API or something than the other Okay, or even like any kind of analytics on the document sort of a Okay, so a lot of these practices are being implemented To improve processes that didn't really work so well or that we can improve right? So if we have like for a company like red hat or a lot of the bigger companies that have different Products and a lot of that, you know stuff came in from acquisitions and some of it is upstream or whatever So you can kind of test out Saying like if I show you this document You can do that but what we'll do specifically now is we've implemented something called a closed loop program Where we actually reach out to customers and we say hey give us some feedback on our documentation like what do you like? What do you not like do you like the way that we construct these tutorials or you know? Do you want to see some architecture guide? You know do you want to see more coded more deployment examples? You know so we do communicate With our users and also with the communities because you know it's all kind of linked together, right? So for an open source project your users are your contributors, right? So and most of the time from what I can see they can be pretty vocal about what they like or not like right? So you normally don't have to seek out feedback From your users because they will they will tell you you know, but yeah It is it is something that we try to implement as well. I was just wondering. Thank you for talk. Of course. It was very nice The where is within I guess in multiple organizations that you've done this have you seen the organizational position of documentation and documentation writers change because for example right now when I go and Look at the documentation for Google or any other bigger company that want to promote the product It's more in the marketing area of things rather than for the people Like you know right so it also depends. So thank you. So it also depends On who your audience is right? So if I write for developer products, then I wouldn't necessarily Have it under the marketing organization So for most of my experience the technical writers have always been under the engineering organization, but About a year and a half ago or something like that at Red Hat We actually got moved to the customer experience and engagement organization So we are in the same that so this is the first time that the technical writing department where the organization is in the same place as people who deal all the people who deal with the customer so support and account managers and so We've been moved from like hiding on you know behind behind the engineers, you know like to actually being a more of a first-class citizen And I know that It depends on the organization. I can't really speak for things like Google or Or other companies because I don't really know what their work structure is But but yeah, it's it's tricky. It's tricky because I've seen some Technical documentation websites that have really more been just like a marketing spiel and I'm like you really got to have that clear separation Because if if the sort of the more hardcore users are gonna get Very disengaged if you try to you know sell them a bunch of you know give them a marketing spiel I hope that answers your question. Yeah, okay, so this is the last points then Hey, I like it when the programmers write as much documentation as possible because it actually makes their code better They they think about it and they maybe change the code, but when is the time to move and hire a professional writer? That's a really tricky question. So the first of all I Perfectly agree that developers can write documentation for the Components or the software that they code to a certain point, right? So if you have a smaller project It's that doesn't have you know, so as long as okay, I Can't answer that because you have to see for yourself like it's a case-by-case basis But once you start having more than a few components that have to integrate In order to create a solution, right? So once you move from just a piece of software to something more of a solution or a collection of services or components Then you start running into problems because most of the developers were focused on one component or two components Oh, not a whole lot of integration coding Normally happens, right? I mean, I don't know obviously I'm sure there's people who in places who do that But I haven't seen this personally and one of the things that have an advantage of getting a professional Writer or someone who's even take one of the developers who's more Has a broader view So if you're if you live inside this component is gonna be very hard for you to think like a user, right? And as a developer, you're not being paid to think like a user. You're being paid to think like a developer Right? So like when we look at the whole scheme of things, you know You don't have to worry about that because now you have a writer that can help you sort of group everything together So I guess that's the closest thing that I can say to a recommendation You know, it'll be nice if you have one writer for every 10 or 15 developers most of the time It's more like 20 but but yeah, I mean this it mean that used to be the sort of guideline But I sorry if I couldn't answer your question more, you know, I don't have a magic formula So but thank you Please thank my key for the dog and the amazing questions