There are different aspects we could and should document: * User documentation * Developer documentation * Api documentation * Test suite documentation Additionally, this page outlines what good documentation should contain: https://documentation.divio.com/. User Documentation The user docs are what we have in doc/guides/tools. These should contain the tutorials and how-to guides about testbed setup and how to run/configure DTS. There may be parts which would be better placed in developer documentation (such as the docs guidance). Developer Documentation The developer docs should be understanding-oriented. These should contain the architecture, what are good (and bad) coding practices with explanations, what to put into a commit message and so on. There could also be some tutorials and how-to guides. There should probably two parts, one for framework developers and one for test suite developers. The test suite developers docs may actually be in the user docs. We don't a clear where we'd put the developer docs. API Documentation This is the reference mainly for framework developers, but test case developers would find it useful as well. The place to put these has been discussed and would be placed alongside DPDK API docs. Test Suite Documentation This is different from the test suite developer docs mentioned above. The test suite developer docs is about how to implement a test suite and related resources. This documentation is about documenting the test suite itself - what it's testing, what configuration is needed and so one. The place to put this documentation is currently the test suite Python file. If we adopt a YAML-based test case definition file, we may need to move some (or all) of it to the YAML file.