How to judge READMEs?
RichardLitt opened this issue · 2 comments
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?
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.
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.