Since I released my first open source project in October, I did various iterations at improving the README of my project, but I'm not really satisfied just yet.
https://github.com/jmfayard/gradle-kotlin-dsl-libs/blob/master/README.md
I have found surprisingly hard to put myself, who maintains the project and knows every detail of it, in the shoes of the casual developer who would stumble upon my project without any context and not an infinite amount of attention.
Ideally, I would like him after a short read to think either
- that's not for me but I know why
- that's something for me and I will give it a try.
Do you have any recommendations on how to write a better README?
That could be examples of things to avoid, or examples of projects that do it right.
Top comments (19)
I usually structure my READMEs like this:
The structure and content might vary depending on the project but that's the default "template" I use when I write a README.
I like it that way because users just need to take 5 minutes to read it and know what's what.
Very useful, merci!
Hope some of this info adds to the discussion.
Often a gif can be super-helpful to show how a project functions.
Example: github.com/MichaelDimmitt/gh_reveal
An image can likewise provide benefit.
Example: github.com/JohnCoates/Aerial
Logos or other images are also nice, they make the document more fun and less of a pain to read.
github.com/hashrocket/decent_exposure
Also, people often like the "shields" to show numbers like num downloads/week or tests passing.
shields.io/#/
Happy to add to the discussion further.
Mac app I like to use, Giphy Capture, for making gif's
I like to think of a README very much like a college essay. Very formulaic, with a rigid and proven structure, with the intent of getting your idea across as quickly as possible.
While I am by no means an expert (or even really that great at following my own guidelines), here is the general structure I tend to stick with:
My main point to all of the stuff above is that your README should be a springboard to everything that anyone needs to know about your project. It should primarily work to get new users intersted in trying it out, aid existing users in getting to the right channels for help, and hold the important bookmarks that maintainers will keep coming back to. And above all, Your README is not your documentation, but it should link out to the relevant pages in your full documetation whenever possible.
That makes a lot of sense, and I would have probably fallen into the "Your README is not your documentation" trap if you hadn't point it out that clearly. Thanks a lot!
You're welcome! It's definitely a temptation to use the README for documentation, since it is right there and Github displays it nicely for you. But dumping full docs into a README is just going to make it too huge for a new user to easily scan and they will leave disinterested, and it is too difficult to navigate for existing users to easily find what they need.
Github's Wiki is just as easy to use and gives you proper navigation for small, flat documentation needs. For larger and more complex docs, it's probably better to keep your markdown in the project and integrate it with a static site generator1, so that the release of the project also publishes the docs to Github Pages or something like that. Either way, it's better for everyone than putting it in your README.
Orchid is a great choice of SSG for documentation. It can generate full Java or Kotlin API docs along with wikis and blogs and publish it all to Github Pages automatically, and it integrates seamlessly into your Gradle build
</shameless-self-promotion>
ย โฉI actually put the full license in a dedicated file and the "license" section of the README only contains a link to it. That's probably a bit redundant but it's an old habit from the time when GitHub did not include the license in the project page header.
That's usually something I put in the full documentation to keep the README more lightweight and free of unnecessary technical details.
This article is pretty good about about the structure of README files: medium.com/@meakaakka/a-beginners-...
It also contains a template that you can reuse.
I especially like it when the contributors with avatars are listed at the bottom. It adds a great human touch.
Conciseness is key. My experience of READMEs has been when I need to learn something and being able to pull out the essentials. I think the README you linked is way too wordy and would suggest trimming it down.
I always thought of README as a quick look over a project: what is it about and how to set it up quickly with some examples and a link to the documentation in case I need it. In this area, after a quick look on yours, I think it does it perfectly.
I'm currently writing a post on this, I'll send you a link when it's done.
However, according to me the core idea is the README should be a gateway to other pieces of info. Keep minimal info in the README, like how to install, a quickstart code sample, and links to the contributing, docs, license etc. Only exceptions when your project is really tiny
Looking forward to reading it :)
Writing README along side with source code/feature development.
If you separate README development from source code development, you're doing it wrong.
Treat README like source code, it's an art.
So the answer is: it actually depends on the project itself.
I just came across this README generator that might be useful you:
github.com/kefranabg/readme-md-gen...