Actually, I think the answer is within your question, you already say that:

• you do not have any prior knowledge about design patterns
• there's no kind of resource on Youtube and stuff
• the docs do not hold a section such as getting started or introduction

As Tapas Adhikary has mentioned, you would go to source code itself and try to understand the intention. However, this approach conflicts with your "no prior knowledge" statement. For you to understand a codebase, you should know design patterns and you said you do not know that. Well, to tackle this problem with logic, you would simply refer to a mentor, a senior and ask them to explain how to utilize the codebase.

However, before doing that, you should have asked yourself another question: Do you really want to use that source in your project? I mean:

• a project that does not have any external resource on Youtube or blogs also does not have a mature, at least minimal, community
• a project that does not introduce itself is maybe subject to change in the future or just a hobby project, if these projects do not tackle alpha releases, they are to be abandoned
• if you do not know any design pattern, maybe you should start to learn, it is the fundamental of software development

There should be standards to use an open source project in your software development team. You should refer to your seniors but below are convenient to judge a project:

Convenient Ways to Review Open Source Projects 101

Requirement Levels

Level 1: Minimal Requirements

• The code should be tested. It is to prove (i) that the software works as intended and (ii) the developer of target codebase is aware of the risks of regression in the future changes.
• You should also judge when the latest change was in the open source project. There's not a clear anwer as to when. You should do this to ensure the OS project is relevant to its current environment. If you want a time limit, let us say, 1 year. If the latest change is older than 1 year, then we can safely assume that the project is abandoned.

Level 2: Optimal Requirements

• The developer of the OS project should provide the coverage or a method for you to compute the coverage of the codebase. With this, you can measure how much of the codebase is tested.
• The developer of the codebase should provide you an API doc. An API doc shows you how the codebase is structure with docstrings that help you understand the units and what their purposes are in the project.

Level 3: Maximal Requirements

• The developer of the OS project should provide easier and automated report about the various aspects of the project such as builds, testing in many version-differing environments and coverage. Today, the platforms like TravisCI, Codecov and Coveralls make this automation a child's play and usually, Shields badges are standard way for quick reviews.
• The developer of the OS project should provide a more-welcoming, human-readable doc which will definitely include sections such as "Introduction", "Getting Started" and/or "Installation".

A Case Study

A Level 3 Example

You do not suddenly say "let's use this" for every OS project you will find on the internet. You should review them and judge them. For instance, let's look at Ionic.

• Ionic Documentations
• Ionic Repo

There are introductory sections in the Ionic framework documentations. However, its repo does not provide a way that shows their builds or coverage, it only has badges that shows NPM versions. So, it is kind of friendly, but I will have trust issues about how it functions. On the other hand, on their main page, I see many referrals, which means it is battle tested in the industry somewhere, which makes my worries about its build process fade away a little.

My Repo

So, I've been maintaining a project called tgcli.

• tgcli repo
• tgcli docs

You see many quick and automated badges about its builds, coverage, pypi version, which Python versions it supports, which license it has, how much it is downloaded by the real users in the last month and its coding style.

You visit its documentation and you see a "Getting Started" section, which contains information about how to install and use it, even to an extent that how to set it up in an environment. And the documentation is separated to sections.

---

Final Words

You need to review the project you are going to use. If you are in a desperate need of using it, like there's no alternative to it in the real world, then:

1. You review the license of the code, make sure it is not GNU GPL v2 and below. If it is something else, you can review what you can do with it by seeing the license in TLDRLegal.
2. If above condition is met, you copy the section that you need and adapt it to your needs.