Think of it this way:
how much documentation would I like to be available when I visit an open source project?
Answer: a lot
how much documentation is enough?
Answer: there is never enough documentation!
Now there are several things to consider:
Making a great first impression matters
For this you want to have a clear one liner that describes your project and a good README. These will be the first documentation that a user will see. On Github this means using markdown or ReST to create a concise and comprehensive README with several questions that I would expect to find answers about your project:
- explain why this project exists?
- what does your code?
- how to use it in a minimal way? and how does it works at a high level?
- is the code stable and tested? if you have a CI running your tests, put CI badges in that README. Tests serve also as documentation for your code.
- how to download and install it including URLs to its home page, repos?
- how can I get support? (e.g. tickets, mailing lists, IRC, etc)
- what is the license for this code?
- URLs to more detailed documentation (when this is ready... you may not it have right at the start)
- What are alternative projects that do the same thing?
- How can I contribute to your project? Do you accept pull requests? Patches by email? What do you expect from a patch in terms of coding standards, etc
That's a lot but I would expect this. Here are some examples:
(Note: I am involved with these projects and I do not claim their README is perfect, far from it).
Built-in UI & CLI documentation
Next you want making your code as easy to use as possible. If you have a UI or a command line interface, make sure that this contains as much built-in usage help and documentation as needed. If this is a library, make sure that your functions are documented using your language conventions (e.g. this would be docstrings for Python).
Tests are documentation
Next you want tests: test code serves as a great documentation especially for libraries and beside that they are kinda useful...
Running the tests on Travis, Appveyor, Circle and similar is important of course.
Formal manuals and documentation
Next is actual formal documentation. The convention is to store this in a
doc top level directory. On Python, most folks use ReST for writing docs. You would want to cover a few things:
- a usage guide
- an installation guide
- if needed a troubleshooting guide
- some FAQ
- an API documentation: if your project is also a library you should generate an API documentation based on the documentation present in the code. For Python, this would mean using something like Sphinx to generate the doc.
You should publish that documentation on a web site. https://readthedocs.org/ is a great resource for this.
Here are a few decent examples:
I hope this helps for a start!