Your project should include a single, centralized documentation entrypoint that offers pertinent information: what the package is and does, how to build it, use it, test it, contribute to it, what license it is under, etc.
Customers abandon projects that are not easy to grok. Time is expensive, and not offering that simple, one-stop-shop documentation point imposes just that extra cost that tips the time scale.
How this is done needn't be described too far in-depth. It is really up to you.
Markdown seems to offer a good compromise between human-readability and machine-enhanced presentation layer.
At a minimum, the central document should include the following:
-
what the package is and does;
-
how one uses it;
-
how one installs it;
-
what license it is under;
-
who built it;
-
how to test it and use the continuous build;
-
how to get in contact with its maintainers;
-
how to report issues; and
-
how to contribute.
If these points are defined in more concrete documentation elsewhere, the central document should make allusion to it—without necessarily duplicating the content ad nauseum.