Last active
January 16, 2024 15:11
-
-
Save hendrikebbers/72ad8fa24548c3253f7c4977d8f0533a to your computer and use it in GitHub Desktop.
README template
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Name of the project | |
This is a short section that explains in an non-complexe way the main usage of the project. Should be like 3-8 sentences. | |
table of contents need to be added at this place. | |
## Getting Started / Installation | |
Since Github is used mostly by developers it makes sense to start with a section that shows how the content of the repo | |
can be installed. | |
### Prerequisites (possible sub-section) | |
For some tools it is important to have a system that is configured in a specific way. | |
Or maybe the repo contains a JS lib and a node version is needed on the system to build the lib. | |
All that information should be added in this sub-section. | |
### Installation (possible sub-section) | |
This should always be the first sub-section that gives an overview how you can install the content of the repo. | |
If it is a tool or a service it makes sence to give an overview how it can be installed on your system or a server. | |
If the repo contains a lib or api it makes sense to show how it can be added to a project. | |
It is ok to add sub-sections to this section if ypu for example need to provide seperate installations guides | |
for different operation systems. | |
If "Installation" is the only sub-catergory of "Getting Started" the content can be placed directly under "Getting Started". | |
### Build (possible sub-section) | |
For developers it is often interesting how a software can be build. | |
Even if the artifact of a lib is publicly available it makes sense to add documentation how a dev can build it locally. | |
If the description of the build is easy (like a simple Maven / Gradle project) and contains only 3-5 sentences it | |
should be placed here. | |
Otherwise the "Build" section should be placed below the "Usage" section. | |
## Usage | |
This section contains the general (technical) documentation of the repo and how it can be used. | |
Depending on the repo this section can become quite long. | |
If the repo contains an api the most common usecases should be shown by code snippets and description. | |
For a tool it even makes sense to add images of the tool when describing common workflows. | |
## Want to Contribute? | |
TODO: Here we can have a common text that is the same in all repo but can be overwritten / extended with some specific | |
information. | |
## Licence | |
All content of the repository is distributed under the FOO License. See our [LICENSE.txt](LICENSE.txt) for more information. | |
If you are new to open source and not familiar with open source licences we recomment you [this article](foo). | |
## Contact | |
Here we add some contact information | |
## Links | |
The following links provide additional information about the project and the FOO foundation. | |
- [Blog about Bar](foo) | |
- [Page of the Foo Foundation](foo) | |
- [Tutorial about the integration on YouTube](foo) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment