It's a comprehesive set of advices in general. My personal favorite is to plan the Getting Started to be accomplisheable in no more that 30min., and use short s

It's a comprehesive set of advices in general. My personal favorite is to plan the Getting Started to be accomplisheable in no more that 30min., and use short sentences, if possible. Even though the advices are generally applicable, I read them from a sole developer prospective. From that angle I think the most important is to describe the main use case and then any major features. Pointing a user to some [preferrably annotated] test-cases is equally effective way to explain what could be done. Having a built-in help of whatever level of detail and polish is the next priority in my view. If one is able to expand this into a full-blown doc, then just explain whatever you care your users to know to be able to use your product. Basically, the emphasis is on the making the thing useful first, then put the efforts into the verbal packaging. We all know, that the code will need maintenance, so will the docs. So not everyone could afford to prioritize both. In open source, I'd appreciate any doc at all, just let me know of the utility. Would not worry that much about typos and such. Sure it's easy to check, but fear not, these serve almost like an invitation for users to contribute their part into your project. Well, who knows, some may be inspired and more able to help you with a full-blown and effective doc!