How to judge READMEs?

[RichardLitt]

PR #50 has made me wonder what makes an awesome README a bit more than the other more recent PRs have. There are a ton of great READMEs in this list, but they are all starting to look the same to me, and I suspect people are using the list as an advertisement scheme for themselves instead of as a way to point out ridiculously good documentation.

There are some procedural changes we could put in place to stop this: for instance, asking that PRs get a +1 from a non-contributor before merging, or disabling self-submissions. Another would be having submitters explain why their README is more awesome than others on the list, as a way of judging fitness.

What do you think?

[waldyrious]

I don't think that requiring +1s in PRs or disabling self-sumbissions would necessarily be a net positive. The former would make PRs stale if nobody else is paying attention, which is unfair; and the latter provides no hard guarantee of quality: there is of course a correlation with a third-party having evaluated one's documentation and deemed it good, rather than self-evaluation which is naturally biased; but the reverse relationship does not hold (a self-submitted entry can still be a great readme).

As for adding explanations for each entry, that's a good thing IMO and is closer to a solution for this issue; but IIUC that is already the case, right?

IMO the best way to address the core problem is to collaboratively define a set of guidelines that a good readme should follow (something similar to the standard readme spec, but focused on nice extras rather than basic requirements) so that submissions have a concrete set of boxes to tick.

Some of the things I'd consider marks of a good readme:

• title and short description of the project
• badges (build status, maintenance status, issue stats, etc.)
• table of contents if there are more than, say, 3 sections
• installation and usage instructions, with copy-pastable commands
• dependencies / prerequisites
• contribution guidelines
• birds-eye overview of the project (what files exist, how they are organized, what each one does, how they relate to each other...)
  • bonus points if presented in a systematic form, like a table
  • bonus points if presented in a visual form, like a graph or diagram
• screenshot (static or animated) of the project in action

And likely others I'm overlooking right now.

[ronny-rentner]

I think one important aspect of READMEs is that they are easily readable in a text editor without rendering.

Though, if you check this out from the list https://raw.githubusercontent.com/ma-shamshiri/Spam-Detector/master/README.md I'd say it's more an HTML file than a README.