ownCloud Documentation

1. The platform and tools used to build the documentation is Antora.
2. The file format that the documentation is written in is AsciiDoc.
3. The UI & UX of the documentation can be found at docs-ui

Table of Contents

• Antora Site Structure for Docs
• Documentation Guidelines
• Contributing to the Documentation
• Generating the Documentation
• Common Content and Styling the Documentation
• Best Practices and Tips
• Target Branch and Backporting
• When Does a Change Get Published to the Docs Web Site?
• Create a New Version Branch for Docs
• HTML to PDF

Antora Site Structure for Docs

Refer to the Antora Site Structure for Docs for more information.

Documentation Guidelines

Refer to the Documentation Guidelines for more information about backgrounds and processes.

Contributing to the Documentation

To get started contributing to the documentation, please refer to the Getting Started Guide.

With regard to language and style issues, consult the Style Guide.

Generating the Documentation

IMPORTANT
We recently have upgraded to node 18.19.0. In case you used a lower node version for your local doc repos, you must upgrade them all. See the link below for details.

IMPORTANT
We recently have upgraded to Antora 3.1.7. In case you used a lower Antora version for your local doc repos, you must upgrade them all by running yarn install in each doc repo.

To generate and view the documentation locally or planning major changes, refer to the Building the Documentation guide.

Common Content and Styling the Documentation

If you want to suggest an improvement to the ownCloud documentation theme, such as the layout, the header or the footer text, or if you find a bug, all the information that you need is in the docs-ui repository. Changes made in docs-ui are valid for the whole documentation.

Please read how to test un-merged docs-ui changes with content from the ownCloud documentation.

Best Practices and Tips

Refer to Best Practices and Tips for writing in AsciiDoc for more information.

To check for broken links manually, see install and use a broken-link-checker.

Target Branch and Backporting

Please always do your changes in master and backport them to the relevant branches. The ONLY reason for doing a PR in a branch directly is, to fix an issue which is only present in that particular branch! When creating a PR and it is necessary to backport, document in the PR to which branches a backport is needed.

When backporting, consider using the backport script which eases life a lot and speeds up the process. It is also very benificial when using the extended code provided, because a clear naming structure of the backport PR is generated automatically.

When Does a Change Get Published to the Docs Web Site?

Changes made will get published to the web under the following conditions:

1. A merge in a component to one of the defined version branches triggers as a last step a master branch build.
2. A merge to master triggers a site build which then pushes all versions defined in site.yml.

Create a New Version Branch for Docs

Please refer to Create a New Version Branch for Docs for more information.

HTML to PDF

At the moment, creating a pdf from a component via Antora is broken and will be fixed past updating to Antora 3. In the meanwhile a workaround is provided, see the HTML to PDF description.