Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align on either Markdown or Asciidoc documentation #256

Closed
sschuberth opened this issue May 20, 2024 · 9 comments
Closed

Align on either Markdown or Asciidoc documentation #256

sschuberth opened this issue May 20, 2024 · 9 comments
Labels
documentation Improvements or additions to documentation.
Milestone

Comments

@sschuberth
Copy link
Contributor

The project currently makes use of both Markdown (4 files) and Asciidoc (22 files) for documentation. For consistency, documentation should be aligned on either format.

@mnonnenmacher mnonnenmacher added the documentation Improvements or additions to documentation. label May 20, 2024
@mnonnenmacher mnonnenmacher added this to the 1.0.0 milestone May 24, 2024
mnonnenmacher added a commit to boschglobal/ort-server that referenced this issue May 30, 2024
Convert all readme files in the repository from AsciiDoc to Markdown to
use the same lanugage for all of them. While at it, format all of those
files to use the one sentence per line approach to minimize the diffs
when the files are edited.

The conversion was done by converting the files using asciidoctor and
pandoc:

  asciidoctor -b docbook5 README.adoc
  pandoc -f docbook -t gfm README.xml -o README.md \
    --base-header-level=2 --wrap=preserve

Afterwards any problems were corrected manually.

Relates to eclipse-apoapsis#256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
mnonnenmacher added a commit to boschglobal/ort-server that referenced this issue May 30, 2024
Convert all readme files in the repository from AsciiDoc to Markdown to
use the same lanugage for all of them. Markdown was chosen over AsciiDoc
because it is the more commonly used format in open source projects and
most developers are familiar with it.

While at it, format all of those files to use the one sentence per line
approach to minimize the diffs when the files are edited.

The conversion was done by converting the files using asciidoctor and
pandoc:

  asciidoctor -b docbook5 README.adoc
  pandoc -f docbook -t gfm README.xml -o README.md \
    --base-header-level=2 --wrap=preserve

Afterwards any problems were corrected manually.

Relates to eclipse-apoapsis#256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
mnonnenmacher added a commit to boschglobal/ort-server that referenced this issue May 30, 2024
Convert all readme files in the repository from AsciiDoc to Markdown to
use the same lanugage for all of them. Markdown was chosen over AsciiDoc
because it is the more commonly used format in open source projects and
most developers are familiar with it.

While at it, format all of those files to use the one sentence per line
approach to minimize the diffs when the files are edited.

The conversion was done by converting the files using asciidoctor and
pandoc:

  asciidoctor -b docbook5 README.adoc
  pandoc -f docbook -t gfm README.xml -o README.md \
    --base-header-level=2 --wrap=preserve

Afterwards any problems were corrected manually.

Relates to eclipse-apoapsis#256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
github-merge-queue bot pushed a commit that referenced this issue May 31, 2024
Convert all readme files in the repository from AsciiDoc to Markdown to
use the same lanugage for all of them. Markdown was chosen over AsciiDoc
because it is the more commonly used format in open source projects and
most developers are familiar with it.

While at it, format all of those files to use the one sentence per line
approach to minimize the diffs when the files are edited.

The conversion was done by converting the files using asciidoctor and
pandoc:

  asciidoctor -b docbook5 README.adoc
  pandoc -f docbook -t gfm README.xml -o README.md \
    --base-header-level=2 --wrap=preserve

Afterwards any problems were corrected manually.

Relates to #256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
@mnonnenmacher
Copy link
Contributor

I would prefer Markdown over Asciidoc for the following reasons:

  • Markdown is far more popular for documentation on GitHub, so more developers are familiar with the syntax.
  • The two tools I would prefer to render the documentation to a website both use markdown (Docusaurus, because it uses React like our frontend, and because it's used for ORT; mkdocs-material, because it seems more streamlined than Docusaurus).
  • GitHub supports rendering Mermaid diagrams in Markdown, but not PUML diagrams in Asciidoc.

One thing where Asciidoc is clearly better than Markdown is the table syntax, that is terrible in Markdown.

@sschuberth
Copy link
Contributor Author

Another plus-side of using Asciidoc is that it's also what ORT's template reporter uses, so getting familiar with the syntax could be beneficial.

@oheger-bosch
Copy link
Contributor

My preference is Asciidoc, because in my opinion it offers a great balance between complexity and feature richness - meaning that for typical use cases it is easy to use (and learn) while offering really nice functionality. Its syntax is clear and stringent; some quirks of the Markdown syntax have already been mentioned.

I am not familiar with Mermaid, but from looking at the website, I am not sure whether it supports all the diagram types we use in the documentation. For instance, PlantUML supports complex deployment diagrams with default elements for nodes, databases, message queues, etc.

Another benefit I see is the support in tools like docToolchain. Here multiple documents can be combined to generate documentation in different formats, including websites. We use this internally to deploy our arc42 architecture documentation to GitHub pages. Such an approach could be used to solve the problem that PUML is not rendered natively by GitHub.

@sschuberth
Copy link
Contributor Author

I am not familiar with Mermaid

FYI, I've been enjoying to use https://mermaid.live/ to learn Mermaid.

For instance, PlantUML supports complex deployment diagrams

Whatever diagram tool we use, for me it's (very close to) a must-have that GitHub can render it as part of its documentation. Less preferably, diagrams would only be rendered when deploying a website or so (in case of Asciidoc, maybe using Antora as an alternative to docToolchain).

Also, we should keep in mind that there might be nice features in Asciidoc per se, which however are not supported on GitHub, see e.g. this issue.

For reference, there are also more Markup languages supported we theoretically could choose from.

@mnonnenmacher
Copy link
Contributor

My preference is Asciidoc, because in my opinion it offers a great balance between complexity and feature richness - meaning that for typical use cases it is easy to use (and learn) while offering really nice functionality. Its syntax is clear and stringent; some quirks of the Markdown syntax have already been mentioned.

Are there any specific issues with the Markdown syntax except for tables?

I am not familiar with Mermaid, but from looking at the website, I am not sure whether it supports all the diagram types we use in the documentation. For instance, PlantUML supports complex deployment diagrams with default elements for nodes, databases, message queues, etc.

I don't think we have a big need for complex diagrams, but if Mermaid is good enough for the Kubernetes docs it's probably also good enough for us:
https://www.kubernetes.dev/blog/2021/12/01/improve-your-documentation-with-mermaid.js-diagrams/
https://kubernetes.io/docs/contribute/style/diagram-guide/

Mermaid supports C4 deployment diagrams (comptaible with the PUML syntax):
https://mermaid.js.org/syntax/c4.html#c4-deployment-diagram-c4deployment

Another benefit I see is the support in tools like docToolchain. Here multiple documents can be combined to generate documentation in different formats, including websites. We use this internally to deploy our arc42 architecture documentation to GitHub pages. Such an approach could be used to solve the problem that PUML is not rendered natively by GitHub.

I believe that there is a lot more tooling available for the Markdown ecosystem. docToolchain looks pretty oldschool, but maybe it's styleable. Some examples for Markdown:

@mnonnenmacher
Copy link
Contributor

As there have been no more comments after my last post, I will make a PR to complete the move to Markdown, this will also make #881 easier.

@mnonnenmacher mnonnenmacher modified the milestones: 1.0.0, 0.1.0 Sep 30, 2024
@sschuberth
Copy link
Contributor Author

As a status update, currently there are still the following *.adoc files in the repository:

docs/architecture/different_tool_versions.adoc
docs/authorization/authorization.adoc
docs/config/config.adoc
docs/db/db_schema.adoc
docs/development/helm.adoc

@sschuberth
Copy link
Contributor Author

By now only these are left:

docs/architecture/different_tool_versions.adoc
docs/config/config.adoc
docs/db/db_schema.adoc

mnonnenmacher added a commit that referenced this issue Dec 20, 2024
This requires to reformat the file with `pnpm format`.

Resolves #256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
mnonnenmacher added a commit that referenced this issue Dec 21, 2024
This requires to reformat the file with `pnpm format`.

Resolves #256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
mnonnenmacher added a commit that referenced this issue Dec 21, 2024
This requires to reformat the file with `pnpm format`.

Resolves #256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
github-merge-queue bot pushed a commit that referenced this issue Dec 21, 2024
This requires to reformat the file with `pnpm format`.

Resolves #256.

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
@sschuberth
Copy link
Contributor Author

This was resolved by #1694 (auto-close failed again).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation.
Projects
Status: Done
Development

No branches or pull requests

3 participants