Sphinx-Metrics
Will I build it?: probably not
Metrics from Google Analytics, Grafana and co. right inside the documentation.
Problem
How often a page is read or how a project develops lives in tools like Google Analytics or Grafana. Readers of the docs see none of it – and anyone looking for the numbers first needs access to those tools.
Solution
A Sphinx extension fetches metrics from external sources and shows them right in the documentation, e.g. page views per chapter or build times. New sources plug in as exchangeable "drivers".
Tech
Python, Sphinx extension with its own directives; drivers for the APIs of Google Analytics, Grafana and co.; fetched at build time with a cache.
Smart Code Block
Will I build it?: likely
Show code and its result from one single source.
Problem
When you document rst or Markdown, you often show the code and the result next to it. So the same code sits twice in the file: once as a code block, once to be executed. Change only one, and they no longer match.
Solution
A "smart" code block that creates both from one source: the code and the rendered result – for example in two tabs, "Result" and "Code".
Tech
Python, a Sphinx directive that parses its content and also outputs it as a code block; tabs via sphinx-design.
Sphinx-Autosar
Will I build it?: probably not
Document AUTOSAR architectures from ARXML files and link them to requirements.
Problem
In automotive projects, the software architecture lives in AUTOSAR ARXML files. Requirements, specifications and tests live elsewhere. Linking the two is mostly manual work.
Solution
A Sphinx extension reads ARXML files and generates architecture documentation from them, similar to an API reference. Software components, runnables and co. become Sphinx-Needs objects that can be linked to requirements and tests.
Tech
Python, an ARXML parser, Sphinx-Needs for objects and traceability.
