The clarity of readme files is critical for software developers. That information varies from installation instructions to potential bugs and depends on the nature of the software. Fortunately, there is a set of good practices to follow if you want your ReadMe to be neat.

While there are no hard and fast rules, every ReadMe file needs to be easily understood and contain accurate information that helps users get the most out of your software. Following the eight guidelines listed below, you can help developers leverage the software’s benefits and head off potential problems down the road.

1. Summarize what your software does in the introductory paragraph

All good writing, including technical writing, begins with a clear summary of what you’re writing about. Begin with an introductory paragraph that tells readers the purpose of your software and its major benefits. Give them a summary of the information you will include in your ReadMe using clearly defined sections.

2. Organize your information to make it easily accessible

While every ReadMe is different, most should include sections like general information, getting started, included technologies, setup, tests and any bugs or problems. If you mention libraries, provide links to these. Your ReadMe file should include such elements as tech description (language/framework used with version), database, patterns and setup.

3. Provide key facts in your general information section

The general information section should expand on the summary you provided in your introductory paragraph to give readers a better understanding of your project. Include a brief description and answer the question, “what problem does this project solve?”

Include an outline of the technologies in the project, such as framework (Rails/iOS/Android/Gameboy Colour), as well as programming language, database, ORM, links to any related projects (for example, whether this a Rails API with corresponding iOS and Android clients), links to online tools related to the application (such as the Basecamp project, the dropbox where all the wireframes are stored and the JIRA project).

4. Show users how to get started

In your getting started section, include a detailed spin-up process with instructions for installing any software the application is dependent on (such as wkhtmlopdf, PostgreSQL, XQuartz). Give instructions on running the app. Finally, include information about subdomains in the app (e.g., api.myapp.dev/), other tools configuration (e.g. Stripe, Amazon), and test data info. This way you will let the developer start working with on your project faster.

5. Explain testing procedures

Give users explicit instructions on how to run all necessary tests. Explain the libraries, such as Capybara or Cucumber, used for testing your software and supply all necessary commands.

6. Describe common problems and bugs

This point requires open source mostly. Be aware of any problems with your software and describe them to your users. The bugs/issues included in the ReadMe should always be specific and include solutions. Be sure to add information about solutions to the bugs you know.

7. Explain and provide access to staging/beta environments

Users will need access to all included staging environments to fully understand how to navigate them. Provide instructions for connecting to servers and tell clients how to obtain necessary permissions.

8. Remember about ReadMe updates

It’s important to stay one step ahead of the problems by regularly updating and maintaining your ReadMe file. When you add new tools, be sure to proactively test each before you incorporate them into your file. You should update the ReadMe file anytime you implement changes within the setup, configuration or technologies used.

Conclusion

A ReadMe file is often a developer’s first introduction to your project. If it’s clear and gives them relevant information they need, you’ll make other developers’ lives much easier, let them save time while introducing to the project and… keep calm by avoiding unnecessary frustrations. To be effective, your ReadMe should both engage your clients and be fun to use in open source projects.