Project - Documentation

This article contains project ideas related to improve GNU Octave's documentation. For general project ideas, see Projects.

News

• GNU Octave applies for the Google Season of Docs (GSoD) 2020. Potential participation will be announced on May 11, 2020 at 12:00 UTC. Discuss about your ideas and application with us by using Octave's
  • maintainers@octave.org mailing list (please bottom post!)
  • #octave IRC channel in Freenode

Existing Documentation

For a comprehensive list see Publications about Octave.

• Texinfo user documentation for the Octave interpreter.

• Doxygen documentation for the internal C++ classes and external API.

• This wiki:
  • FAQ
  • Resources: Tutorials, Examples, Tips and Tricks, ...

Suggested Projects

Octave's interpreter documentation

Description

The documentation for the interpreter is presumably the oldest, long grown documentation of the GNU Octave project. It is mostly written in Texinfo and strongly interleaved in the Octave build process, i.e., it is necessary to build Octave from source to generate included figures. Additionally, large portions of the Texinfo source are auto generated to stay close to the source code to avoid stale documentation. A special type of this auto generation are the so-called "docstrings", which are extracted from both C++ files and Octave's own script files (m-files).

The resulting Texinfo sources are translated to Info, PDF, PostScript, and HTML, whereas the HTML is further processed to match the QT Help Framework, which is displayed in Octave.

Improvements

• Check for inconsistencies in the manual, e.g., outdated descriptions, awkwardly ordered information, ...
• More examples and demo files for using each Octave command.
• More figures to demonstrate Octave's plotting capabilities, but regard doc size and building time.
• Think about a superior organization/splitting of the manual. Currently it covers many topics interleaved: user manual, function reference, developer guide.
  • Idea for a function reference including Octave Forge packages: https://octave.sourceforge.io/docs.php (unmaintained)
• Document the documentation building process (e.g. rename and document involved scripts).

Long term goals / highly controversial within the community

• Syntax, structure, and readability of Texinfo is a burden for some developers and newcomers. Consider replacement by
  • CommonMark/Markdown
  • reStructuredText / Sphinx
  • ...

Resources

• Style Guides

Contribution guidelines#Coding style

• Source code

https://hg.savannah.gnu.org/hgweb/octave/file/tip/doc/interpreter

• Required skills

Texinfo, hg, building Octave from source

• Potential mentors

Kai

Octave's internal documentation

Since 2013, Octave makes use of Doxygen for it's internal documentation. Ever since, there has been moderate effort to add Doxygen comments to the entire code base or to create verbose descriptions for key techniques about how Octave works (here an example for important Octave macros). Potential reasons for this circumstance are:

1. Lack of developer knowledge (code grew over 25 years), many "cryptic" macros, very complex class inheritance trees:
   • liboctave/Array
   • libinterp/octave_base_value
2. long build time to see results of documentation effort
3. huge size (about 2 GB), very impractical to "carry around", https://octave.org/doxygen slowly responding

Nevertheless, there is a need for internal documentation:

1. Comprehensive documentation of Octave's external code interface.
2. Enable newcomers (e.g. GSoC students) to study Octave's code easily.
3. Avoid knowledge drain (bus factor).

As Octave's GUI makes use of qt, Doxygen might also be replaced by QDoc with comparable markup.

Resources

• Style Guides

C++ style guide#Doxygen

• Source code

https://hg.savannah.gnu.org/hgweb/octave/file/tip/doc/doxyhtml

• Required skills

Doxygen, hg, building Octave from source

• Potential mentors

Kai

Octave's wiki

Flesh out this wiki.