haiku/docs/develop/TODO
Adrien Destugues a5061ecec5 Generate developer docs with Sphinx
An effort was started some time ago to consolidate all internal
documentation in the git tree. However, this was just an accumulation of
files in various formats without any strucutre or way to browse it,
which results in no one even knowing that we have docs here.

This converts most of the files to restructuredtext and uses Sphinx to
generate an HTML browsable user manual (with a table of content and a
first attempt to put things in a global hierarchy).

There are almost no changes to the documentation content in this commit
(some obviously obsolete things were removed). The plan is to get the
toolchain up and running to make these docs easily available, and only
then see about improving the content. We can migrate some things off the
wiki and website, and rework the table of contents to have some more
hierarchy levels because currently it's a bit messy.

Change-Id: I924ac9dc6e753887ab56f18a09bdb0a1e1793bfd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4370
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
2021-08-27 11:41:17 +00:00

18 lines
1.1 KiB
Plaintext

Documents that still need to be converted to restructuredtext (or thrown away):
- kernel/vm*: it looks like these should be comments in the sourcecode?
- kits/*: TODO, some interesting info in there but also a lot of probably obsolete things
- media/*: some useful things, some sourcecode, and a PDF file about the echo audio driver
Other things to do:
- Organize the table of contents a bit. For now I just wanted to get all the existing files in,
in a mostly flat organization. But it makes things hard to follow.
- Reorganize the directories. For example move midi to kits/midi. Should we follow the layout of
the source tree? Or the hierarchy of the table of contents?
- There are doxyfiles for various components. Unlike the one used for API docs, they scan the cpp
source files and will extract some internals documentation from there. Decide what to do with that.
- Migrate some things from the website. Start with documentation about configure and jam, for example.
- There are TODO lists in various places in the docs, turn them into bugreports in the bugtracker
(including this one!)