I firmly believe in Readme Driven Development. This paradigm is simple:

Write your Readme first.

By writing our Readme first, we force ourselves to think through at a high level what it is we'll be building. This serves as an excellent piece of documentation for ourselves and others to remember what the project is, what it's meant to accomplish. and where it's heading.

In keeping with this, writing a high level README.md is how I started discord-server-info!

Let's look at how I structured our README.md:

Heading

Here are the first three lines of the file:

# `discord-server-info`

> Explore Discord server data and statistics

This follows a standard pattern that I tend to follow for any README.md that I create:

• the first line is an h1 of the name of the project
  • since the name of this project matches the name of the repo, I wrapped it in inline code blocks
• the next line is a blockquote with a one-line description of the project

I like this pattern because it immediately establishes two key pieces of information for a reader:

• how to refer to this project
• whether this project is relevant to them

Readers shouldn't have to read too far into our file to know either of those things.

Introduction

The next section after the heading is Introduction which gives a high level overview of the discord-server-info problem space.

This is essentially a condensed version of the Introduction post from this series.

It allows potential contributors to understand what our project is and why we think it's important.

Technical Overview

The last section is Technical Overview. Where the introduction gives the what and the why, the technical overview gives the how.

This is almost identical to the High level technical overview post from this series.

Since I already have an idea in my head of how we can build this project to accomplish our goals, I've laid out what that looks like at a high level in this section.

This will allow potential contributors to understand the direction we're taking and the general structure of the project.

There's a lot more information I could have included in our Readme but didn't, like specific details for how each package should be built or some of the technical pitfalls we'll potentially face.

Instead, we'll treat our Readme like everything else in the repo and iterate on it.

As we reach the point where we're ready to zoom in on one of the packages and implement it, I'll add a high level overview of what that looks like to our Readme.

This allows us to gain the benefits of Readme Driven Development without getting too far ahead of ourselves.