 Hello everyone. My name is Antei Human and today I will be speaking on the topic quality documentation, the key to open source. Okay. This is about me. I am a person who is a developer advocate at K-Vanu, policy engineer for Kubernetes. I'm a front-end developer and technical writer and open source advocate and I've been a fan of open source since my career started. And I'm also a mesh-mate, otherwise known as a mentor, at layer 5 community. All right, so that's, now that we know a bit about me, let's get into the business of today. What exactly are we going to be looking at during this section. First we're going to be talking about an introduction to open source software and why documentation is imperative in open source software, the strategies for quality documentation, how to achieve an effective documentation, what makes documentation effective in a project and quality documentation checklist that you should look out for. All right, looks like a long list but let's get to it. First and foremost, let's look at what open source software is. Open source software is simply code that is designed to be publicly accessible to everyone and this means anyone can actually see this code, anyone can modify this code, anyone can distribute it as it pleads. And well, as the definition sounds, it's code that is made up for collaboration, right, and there's a frequent misconception that goes on when people hear that open source software is, of course, code that is free to the public. That is, if it's free, why do I have to carefully create this, this code or the documentation behind it or anything for sending this code. It's not like anyone actually cares about it since it's free, right, but then that is a very, very totally wrong ideology and we're going to look at some of the reasons why during this section. But then let's look at why exactly documentation is imperative in open source. In open source software documentation is considered as the core onboarding to when people join a community for the first time, or when people are interested in a particular project. This is because people use documentation of a project to any of them get familiar with the project code base, get familiar with the project community, the community behind a particular project, and of course you walk through the project or the community itself. This is to show you how a lot of person rely on documentation of a project to get a wider knowledge of understanding of a particular project. So why exactly should we care about open source documentation. The quote by Jennifer Reagan says documentation helps users to succeed, which is software and this is confidential. It empowers them to be self sufficient enables them to give further feedback on a particular project. And also, it is organizational backbone for your project. So you can see how in depth that explanation sounds issues that without documentation, what exactly is a great project. That's a big question we're going to discuss in this section. Let's look at a quick survey from GitHub back in 2007. And as you can see this, this, this survey shows that documentation is the number one problems that users of an open source software frequently have issues with either it is in confusion or not. It is either it is incomplete or not, or confusing completely confusing to the users at all. And you actually wonder if the code is meant for the entire public how come it's not carefully look the documentation is not carefully looked after and created. Like I said earlier, lots of persons say if it's free, why do I have to make so much effort towards it, either by contributing to the code base or the documentation and that is completely wrong. We're going to look further into how that is. So why should you care about this documentation in open source exactly. First and foremost, this is code that is made available to the general public. We're expecting contributors from east, west, north, south. So there's a diversity of this diversity in the user personnel that come into that particular project, just get another knowledge. And this could be either users, the end users this could be the sponsors of that particular project. This could also be the designers who want to contribute to this project. This could also be the developers who want to use this project to help themselves in one way or another. So when you think about this, you're like, Okay, so not just one person that's working through the walls of this community to know more about that project. They're like thousands of persons from 1000 fields coming to look at a project. So this is another reason why you should actually look at the documentation. And also, where are users coming from, of course, this users could be coming from a white link link from another article, or they could have just stumbled upon your projects on the search engines, or even on the social media platforms by a tweet made by someone who's curious about your projects, and only to come into your project and find out that it's not as awesome as the person who made, who wrote about it, or who tweeted about it made it look simply because the documentation is not carefully looked at. And also, we should care about the documentation because we want to satisfy the users. Like I said, you don't want the person who heard about your project from someone else, and it's already enthusiastic about the project, walking into that project documentation and being disappointed at all. Well, I thought this was a project I could help myself with this project to solve my problems, but then the documentation says otherwise. And that is a very, very bad picture for your project. And this is another reason why you should also care about the documentation of your projects. And another reason is effectively translating information. Because the code base might be as detailed as the code base of that particular project might solve a universal problem. But if you do not translate that code base into something readable for your audience, then how about user personas that are not familiar with code base and do not have the privilege of actually reading through the code base to understand or looking through the code base to understand what is written down there. Not a lot of persons can do this, of course. So it's effectively translating information, we have to actually look out for the documentation of each and every open source project. So let's look at strategies for quality documentation. And when we talk about quality documentation, we're talking about a documentation that is accessible to everyone, helps everyone understand a project in a very broader sense, in a way that if I go over your documentation for a project, I'll have enough knowledge to actually advocate this project to somebody to actually write about this project if I choose to, to use this project without looking for a helping hand or an extra guide. And all of these are like things that a quality documentation should have. Well, let's look at the strategies for this. To begin with, you have to first understand your user personas. Like I said earlier, there's a diverse spectrum of persons that work into an open source community of projects. Every single day project on GitHub repositories and every single day just to see or to look for projects use cases to solve their problems or their needs in one way or the other. We have the engineers and the engineers work into a project because they probably are working on another project and that's on your project is a tool to complete what they're working on. And the engineers would definitely jump into a project and for an engineer, you can actually look for the documents on the project code piece and have an index knowledge about it, right, because yes he's familiar with the code piece. And then let's talk about the designers. Will you also advise the designers to go and read through the code piece. You have several friends who are designers complain of this singular fact that they want to contribute to this project, but then the documentation for this project does not look like it wants design contributors because it doesn't provide make provision for that. And that is a big problem for most questions. And then another user personality look at is technical writers. They have persons who would want to like write about a project, the use cases and the problem is solved, maybe in an article where they're leasing out of that project and if probably came across yours, they want to include it right there. And in this situation, what happens if the technical writer, of course cannot reach group base of the project. And cannot, of course, translate it in the best way. So how did they actually give this information in their right jobs that you're putting together. Another person and she look at is the sponsors. Yes, you open source, most persons come to project, not because they want to use it, because you see that yes this project solves the particular problem. It's useful to this particular ecosystem, but it's projects of this problem. And as such, I should contribute to this project financially. And so, but before I do that, I want to be sure that what I think of this project is what is it's what my, my financial support, or is what my financial efforts. And that is where you expect your, the user personnel, the sponsors to also look through your documentation and imagine I will continue the communication as a sponsor. And I'm rather disappointed that you press by what you told me about what I heard about the project. And also another user personnel, you should look up for is the end users. Yes, of course, your end users, these persons are the people who utilize your projects, either in production, or either in production, or in its beginning. So, these are the persons that you should also create created documentation for because your end users will not be able to like have an in-depth understanding of this project if the documentation is not as detailed as it should be. And finally, the contributors. And if your project is an open source project, you should look up for contributors big time, because people are eager to contribute to open source projects. And that is something not a lot of persons know about. I've come across thousands of questions, like since I started contributing to open source. Every single one of them is eager to contribute to open source because they feel like, yeah, there's so much exciting things happening when you like collaborate with different persons from different parts of the world on a similar project. There are lots of persons that eager to contribute, but then the big discouragement for them is a documentation or how D2 or how self-explanatory that project has made itself. And then contributors look at this and they're like, well, this is my question of contributing to open source. Let me look at the documentation to see, or let me look at the writer for this particular project to see if I can develop interest or contribute to it. If you look into the documentation, it is not as detailed as it should be. It doesn't provide guidelines on how to contribute. It doesn't actually have any accommodations for contributors on how they can ask for help, how they can get to the code base, how they can get to the documentation of that particular project on the repositories and all of that. It's a very, very discouraging for anyone to have further interest in this project. And the next thing, another strategy is understand what these personas, these visa personas want from your project. Now, of course, every single person is coming to your project with diverse reasons, like we mentioned earlier. The engineers might not spend so much time reading through the documentation because they're already familiar with working with code and them. So if the documentation is just as brief as possible, the documentation, an engineer will be more than happy to actually just glance to it, look for the points they are looking out for, and immediately starts implementing it for what uses or purposes they need this project for. And then the designers. The designer might want to enhance the project's UI or UI, but then imagine a scenario where the designer has to like read more than just the documentation that's provided, which is barely enough to actually give a broad in-depth detail on this particular project. Now this actually hinders the designer's motive, right? Of course. And then we're looking at the technical writers. The technical writers on the end definitely want to go in-depth reading about this project, bring on the left and right of this project just to make sure that they get all the information that is about this project to put together in the article. So they might be spending quality time on your project documentation or more time than the engineers would. And then the sponsors, of course. A sponsor is probably looking for a place to support financially. And as a sponsor, I walk into a project documentation just to see if this project is worth my financial support. You see that, yes, the project solves a need, but then the documentation process should document the steps on how this project came to be, how the entire team worked towards achieving this goal, how the future plans are, how sustainability this project is, because I wouldn't want to contribute to financially to a project that does not have any plans for sustainability in the nearest future. And so you should also look out for this. And then we're talking about the end users. Now what do the end users want? Well, basically just to use your project. So they might not be spending as much time as it, although the end users might not have the broad knowledge on the software as much as engineers would. But then they most likely wouldn't be spending so much time on your project. You might just spend 30 minutes or thereabouts, glancing through it just to look for the particular tool they're looking for or particular lines to set up on the end, set up the project at the end. And that's just about it. And they will probably not spend as much time as technical writers would on the project. And then finally the contributors. And the contributors on the other hand are persons who spend like tons of time on the project as they're new to this software, they're new to the language, probably the programming language, new to the software. The concept of open source, or the needs like entire idea of soft squares, open source softwares and contributing to it at all. And so you might see that contributors spend quality time on this project. And when you think about this, you're going to realize that yes, all of this person spends like different times on this project looking for different needs to be fixed. And so how does this documentation solve the needs of each and every one of this problem. That is where documentation becomes really, really important. So now let's see how to achieve an effective documentation for an open source project. First things first, what you should be looking out for is to define your project. So it is actually very, very okay to go straight up, write the documentation, what's for yourselves and all of that, but then without defining the vision of that particular project in the documentation, or by defining it in the in the rhythm of that particular project or the position rather. Why should users in this project, because of course they will definitely want to see what picture the brother picture that he talked about before putting this software together, because he was up top of an idea, or a problem going to be a bigger problem you want to fix. That is why we went about produce or to put together this software. Now, how do you make your users see the same picture that you see for this project. And that's where the vision comes in. You have to define project vision as detailed as possible and put it together. And another thing you should look out for, you should define the documentation goals, and what exactly is the documentation meant to solve on the target. Like I looked at earlier, you should consider the user personnel. So what goal is it going to solve is documentation just, you know, a dummy site where people can just go through without getting any time to the information or documentation is basically the code base written in words to make it easier for persons to understand or a code base digested in the most simple ways for anyone to get a better understanding of your project. And this is something that you need to define out before you get started. And once you define the goals and the target of your documentation, next thing is to execute this plan. Now how do you execute this plan? You might set a particular timeline that yes within a period of six months, I should have completed the documentation to this end, to this extent, so that anyone jumping onto my project or anyone who comes across this project gets like enough information or enough details to satisfy them about this project that I've created. And so you should follow a timeline for yourself that you have created, of course, now you could do this. There's no better way to do this than with the community behind you. And also, another thing you should look out for is automate and track the project version. For most projects, as the code base is released, documentation just stays there waiting for the data someone is going to automatically work in and say yeah, the code base and the documentation do not correlate. So I'd like to contribute to this. And that is very, very bad for a project documentation. So every release history should be probably documented just as much as a code base is probably documented because there should be a form of synchronism before between your code and the documentation of the code base documentation is a representation of your code base in words. And then another strategy we're going to look at is starting with the README. Now what is an open source project without a properly documented README? Through my time contributing to projects, I know that I usually get hives about the project or whatever. I looked through the README or contributing guidelines and they define the project as much as I wanted to. They tell me why this project was created, how it was created, code created, what problems it solved. And yes, of course README might just be like the summary of your project, but you should make it as interactive and as detailed as possible because some persons might like stumble upon a repository before they come across the documentation. And so in this situation, README would be a subsidies for that. And also, you should make the documentation easy for all user personas to understand. Like we talked about earlier, you have to understand what a user person is looking for and if it means doing a survey on this particular project. Then go right on ahead with it because it's better to take the most times carefully curating the documentation than just doing a rough sketch of what you feel the users would need or what you feel will solve the user's problems and then leaving it halfway, only to realize that it is not even as good as it should be. Also, documentation should be as direct yet detailed as possible. Yes, if the README is going to be as concise and detailed as possible, the documentation should do exactly the same thing and that is why we need to take in as much time and effort as possible, curating this documentation. And like I said, if it means doing a survey on your users and what they're expecting and the areas you should be focusing on why curating the documentation. Then go right on ahead and put in all that effort just to make sure you get the best or get the most while documenting your project. And then we should also, documentation should prioritize sustainability. Of course, there should be a plan and a community behind the documentation to execute this plan. Now, in this situation, I'm going to say what happens after six months after this project has launched and the documentation just stays six months behind because there's nobody actually aware that the documentation is lacking behind and should be improved. And so, what happens five years after this project is created, what happens to the documentation after then, these questions matter a lot because I know I have come across series of projects that the documentation does not tally with the project code base and you might use a line of code from the documentation only to get an error that this particular code is deprecated and you would wonder or you puzzle why exactly a project should have documentation out here. If they're not going to make efforts to improve on documentation to make it up to date with the code base. And this is a discouraging factor for most contributors, because I wouldn't want to like implement or add a line of code from your project, only for it to mess up my own code that I've been working on for probably an entire month or an entire week or entire year, only for your project to mess up my line of code. So that alone is enough to discourage person to utilize your project, contribute to your project or even sponsor your project. And another strategy is we should look out for is to frequently include community for cost documentation, a lot of communities have come across several open source project and this is always an issue. Yes, we're creating the documentation to make it as detailed and concise as possible. But then what is so much words in the documentation if it does not include the community, because this is open source we're talking about, and there's definitely lots of collaboration going on. And like we talked about user personas as diverse as community. And so what is a documentation, if it doesn't include the community as well. So first, you should look out for the inclusively documenting this project. Yes, what if the users are like first time as to open source or first time as to your project, what if they're experts in the project, you should also look out for this. What if they're not experts or they're not first time as and they're just average users who want to, you know, get an in their knowledge of your project. And this also comes as well. And another thing you should look out for is encourage documentation, contributions. Yes, frequently I want to look through this almost like I intentionally look for this in most softwares documentation of most softwares because like so many persons want to contribute to open source. But they're discouraged by the fact that there's a myth that says open source contribution is mostly just code. And which is very, very wrong. Because there's several planning and thoughts that goes towards creating these open source project goes through design. And it goes through like documenting it which is done by technical writers and like several others, several other planning puts together to create this open source project. So if you don't encourage documentation contributions by saying that if you want to contribute to our project, follow these steps or look through this guide to contribute to documentation. Not every user will like just have the thoughts that yes I'm automatically supposed to contribute to this project documentation of course you need to welcome them or give them a heads up that yes you can actually contribute to improving this documentation. And even if they come across an issue on your documentation, it will be difficult for them to report this issue, since the documentation does not clearly state that they can actually go ahead and contribute to this project. So it includes support links. And the last open source project that I looked through. This was a big problem because personally I wanted help from someone in the community and looking through the code base, I wasn't able to like find someone or a particular project. And deep down I thought maybe if I had a link to the community, or if I had a link to someone I can reach out to directly that is responsible for this project code base that can help me out. That was one of my problems, but I didn't see it unfortunately. And I was positive for a moment and I realized I'm not a lot of person actually think through on the support links but this is a very, very important thing to include when creating your open source documentation. And also add a call to participate. You don't want to, you don't want to make it look like you don't need contributions in your project or you don't need help your project. And of course, even if you don't need help, it is an open source project so contributors most likely be eager to contribute a project. And how else can they contribute if they don't see a community behind this project. So there should always be a call to participate in the open source community behind this project because if there's going to be collaboration, there should be a place that the community can engage in outside the repositories. And another thing to finally look at is to look at is to leverage other techniques as I text related content. All the time this is a big problem for most open source project trying to document the code base. They focus so much on words, text, grammar, you know, making everything as complex as it shouldn't be. And you forget that your user person is diverse, you have different users, you have a diverse range of persons, you know, collaborating on this project. So what if the persons that you're, you're, that are looking to this project and scared of so many words. I know I looked at an open source project recently. And, well, what is, what is the word you classify something that is, is worthy, but not comprehensive. Well, I don't know but yeah the project was, it's had a very long documentation, like the documentation as long as it can be. It was discouraging for me to read because like there's so much words, why are there so much words anyway, and I was puzzled because personally I feel documentation can be anything. Your documentation could simply just be videos, videos explaining what this project does, shots demos on this particular project and all of that. And if I look through it, so long as it solves the need I am looking out for that particular project, then I'll definitely count it as a detailed or a good documentation. But if there are like so many words that but yet not comprehensive enough. That doesn't really count does it. So, you should look for other techniques for documenting or creating content outside text related techniques. And this could be either visual documentation like I mentioned earlier, you could practice using or explaining your projects better in documentation, creating shots documentation that explain each and every use case of your project. And here you can have testimonials because people want to see what or who has used this project. And for most persons they use a project because a friend of theirs that they trust use this project, and as I tested that this project is good. And so if you see users that have actually come to testify that yeah this project is awesome I use this either on the social media platform or anywhere that this text is written. You could quickly just take a link to this and add it to your documentation just for referencing, because persons can, most persons use the project based on the trust they have for that particular project, and that project, and that trust can only come about if they have testimonials behind this project. And another way you could actually create your content without write so much text is working samples. Yes, for a project that needs, that needs like hands on demos, then you could take a quick time or a short moment to actually create some work workshops at work labs, just get people have a hands on experience using your project, especially if people have select set up this project on their own systems, then your documentation should include working samples on how they can actually set it up because if you focus more on your documentation on text written content, not a lot of persons might be able to like understand you as much as they should just text. And also you should practice use practice labs. I know that for several projects you might like have them do demonstrations using the your terminal and all of that. So if your project is those kind is a project that requires a terminal and all of that your project should your documentation should have provision for practice labs, where users can actually exercise using this project before setting up on the system, just so you can get clarity on your project and also the documentation should include use cases. What exactly are the different features that this project has and what these features song. This is a question almost every user looks out for on the documentation. I know that whether it's a contributor or a sponsor engineer or a technical writer or designers. They all want to see different use cases for this project and how it can be useful to them in one way or another. In order to do this, your project documentation should clearly have its use cases written out as a features or as a different integrations for this particular project. And also, you should have clear clearly documented metrics. From the time this project was launched down to the current time. How many users have gained so far. How many. How many users from different countries has its games how many contributors of different parts of the world has it had or how many sponsors as it had so far. Most users want to look through this particularly sponsors want to see details like this metrics like this to show that. Yeah, this project is actually it looks like it has a growth potential, and it's a sustainable one because from the time it launched down to this time there's been an exponential growth, which means within a few months or a few years, the growth might be double what it is right now. And so that is why you need to create your documentation using other techniques that are outside just writing bunch of text that people most likely not read it because believe me not a lot of questions read all of that text. And then we have, you can develop your documentation like a developing your code. You see, the amount of effort that is put towards making sure a code functions smoothly, making sure that there's no bug in that particular code, all of the effort that's put into that particular code base. The same energy and the same effort should be used when documenting this project, because it is like the code base is the documentation is a representation of your code base. And so if it's documentation does not give as much detail as code base does, well I don't really see the need for the software being open for users or contributors at all. You should make your documentation, make documentation a requirement for image or release milestone. I mentioned this earlier, your documentation should be in sync with the release of that particular project. And so if there is a version one of that particular project, the documentation should carefully document the version one of that project, the features that were implemented, what was changed, what did she expect in the next version and all of that. And this should like work hand in hand, the project and documentation should be in correlation. And also, you have a well documented process for contributing to documentation. I mentioned this earlier, but it's one thing to invite contributors welcome you can contribute to our documentation as well. That's the question. I know I can contribute to the documentation. How do I do it, because not a lot of persons are not conversations contributing to open source, not to talk of contributing to documentation, because several persons feel that documentation contributions are not done on the repositories for most contributors. And so having a well documented process for contributing will come in really handy for users and even contributors to that particular project and also put documentation and code in the same project. Well, this is not, this is not a mandatory thing. But for most projects for easy access for the users and the contributors, it is always advised that the code base and documentation for that code base should exist in one repository. For easy access and also to like be able to track the, the progress of the documentation in accordance to the progress of the code base. And so it's better or advise that both the code base and the documentation of the project stay in one repository. Although like I said, it is not a mandatory option. And moving forward, let's look at what makes a project ineffective. Several reasons, like tons of reasons, but then I listed out if you hear, I've come across series of open source projects and people will be like, why are you not hyped about this project as much as you should be. Well, it's simple. The project myself like a thousand reasons globally, or it might be the life saver tomorrow. But if I come across this project and it doesn't solve the need that I'm looking for perhaps I want to write about this project and documentation doesn't solve my need. I definitely don't want to be the best reviews about this project. And that goes to every user or every contributor that is coming to your particular code base. And so what makes your project not as your project documentation not as superb or as effective as it should be. First is your project probably focus more on quantity over quality. Like I said, having so much words, so much text, so much writers and like every single page swiped through on your documentation. There's like over 2000 words on a particular page. Yes, of course we understand that you can write down everything word to word, but then there should be other ways you can actually explain this project without having to write so much words or so much text. Because not a lot of person spent the entire time reading through the text and I recently carried out a survey using using Google analytics on a project and I realized that number, the amount of read time for most persons is five minutes. The highest you would see for a user is five minutes. Most persons just look through the documentation for two seconds. Most persons just look through for three seconds or one minute or two minutes. And the highest you'd be looking at is 10 minutes or 20 minutes. That is if the person is really, really looking for answers and has to search through. Else, five minutes is maximum for a lot of persons who want to like better understand improvement. So if you see that if you focus so much time on writing a lot of text, that's not actually passed down the information that is expected. That is also an effect, an ineffective documentation and also focusing more on being repetitive while writing. Imagine the intro page of your projects has this project helps to decentralize the open source ecosystem. This project helps to bring people together and only for me to move to the about page or another page on that particular documentation to see the exact words and exact terms that you use in explaining this project. Yes. That also doesn't count as effective documentation. And also we have incomprehensive documentation. Yes, your project might be as detailed as this should be, but then how explanatory are the words to the users. Remember we have diverse spectrum of users coming to your project. And so what is it comprehensive enough for an expert as much as it should be for a beginner using your project. And these are the things that you should consider and if it doesn't then there's needs to improve on this documentation. And also we have documentation is done by developers alone. I'm not saying it's bad for documentation to be done by developers, but the way a developer would write the documentation is far different from the way a technical writer or someone who has experience on documenting contents would. And of course, developer will use mostly technical terms to explain everything. And so what happens to technical writers who want to read more about your project. This also counts as ineffective documentation. And also when documentation is done posts development. Now, a lot of persons always feel or get impression that documentation should be the last thing that should follow suit after the project is completed, which is completely wrong. While you're following through this particular pattern, you're likely to miss out on the major points that you did or the major features that implemented in the code base, and your documentation will end up not having these points which are also relevant to the users. So they are creating a project from the beginning of that project down to the end. And then finally when you launch the project, we should be documenting alongside. And also inconsistency across documentation. Yes, this also counts as an ineffective documentation steps or plans, and also no support links. We looked at that earlier. We don't want your users to always have to look for your email via LinkedIn since they saw that your person behind or your person behind a particular project so they have to be for email via LinkedIn or such your names on their search engines before they actually ask for help right so your your documentation should the documentation that does not have a support link is considered as ineffective as well. And also non inclusive documentation. It is an open source project. Let's have in mind that it is an open source project and so it opens source diversity and inclusion is a priority for every project of every community. And if your project is not as inclusive as it should be, if it doesn't look for if it doesn't think about if your project documentation does not think about the diverse spectrum of persons that are using or contributing to this project, then it's considered as ineffective. And also, if the project documentation does not scale along with the code base, not tracking the releases alongside with the documentation also counts as ineffective documentation. Now you can see that there are several things that a lot of projects do not look out for we created or creating that project documentation right now let's look at some of the checklists for having some of the checklists for equality documentation several persons their criteria for judging a project's equality documentation vary for based on the reports that have I have looked through from surveys and users that have contributed to open source project I have worked with. These are the checklists that I know that a lot of persons would consider excellent projects. First off, if your project answers all of these questions, then your project is, if your project documentation answers all of these questions, then you can consider it equality or effective documentation. Firstly, answer the question, why was this project created? Every single user would want to understand that question, what was this project created in the first place, what problems does this project solve? Of course, your projects must have thought of an idea that a problem that exists in the society and then you want to solve that problem through your project and so your documentation should constructively have answers to this question, what problem does this solve? How can I get started with these projects? Yes, of course we have different spectrum of persons coming in. If I want to use this project as a user, how do I get started? If I want to use this project as a contributor, how do I get started? If I am an engineer and I want to implement this code base in my own code base, how do I get started? And if your project answers all of these then it can be considered as quality documentation. And another question is, where has this project been used? And this is where we talk about putting in references for people that have used it, testimonials from people that have used this project, companies or organizations that have used this project. So if I see that, yeah, this project was used by a software or a company that I regard, then I would definitely have more confidence in your project and would definitely refer this project to someone else because I'm like, yeah, it's a reliable project. It's not a project that lacks maintenance, management and all of that. It's a project that lots of persons will be eager to use because documentation is carefully written out and so is code base for this particular project. And then who is currently using this project? You have to carefully write these details down in your documentation for it to be qualified or for it to be classified as quality documentation. And where can I get help? A very, very important question as well. Where can I get help for this particular project? If I need help on a project, on the project's code base, where do I get help? Do I run to the community? Do I run through? Should I look for your email directly? Should I look for you on social media? Where exactly do I go to when I need help for this project? And if this documentation lacks this, then well, it's not as quality as it should be. And also, how can I contribute to this project? We talked about this earlier and we see a detailed contributing guide is as important as documentation itself because you want people to collaborate on your project, right? And in order to do that, you have to carefully write down the steps for people that want to collaborate on your particular project. And then finally, the project should have some live use cases. This could be in form of articles. This could be in form of video content. This could be in form of just lists of features that this project has and how it has been implemented. All of those, but then your project should have all of these requirements or your project should answer all of these questions in order for it to be classified or qualified as an effective or quality documentation. And finally, talking of, now let's look at a quick quote that says, what is a great project without good or quality documentation? Well, I really don't know because documentation is everything for an open source project. If you look at open source projects, every single day you have people from different parts or different ends of the world coming to your project and what exactly is a project that for you, it might be the future of tomorrow. But then your documentation says otherwise or it doesn't, documentation does not put these details down there. Users will definitely know how to get into your brain to figure out the big plans you have for your project or the idea that you imagine for this project before you put it together. Exactly, is a great project without quality documentation and that is a taken question you should ask yourself whenever you're thinking of your project and you decide to let your documentation come behind while improving on code base. And that will be all for today. Thank you so much for listening and thank you for your time. I hope this section has helped in one way or the other, enlightening you on what exactly documentation is an open source software, why it is imperative, how to actually get about creating quality documentation, different strategies you can follow. And finally, how you should make sure your project documentation is top notch, just like your project code base. Thank you so much for your time. You can connect with me via Twitter, you can connect with me via GitHub and drop your questions if you have any for me. Thank you.