Skip to content

Commit

Permalink
Merge pull request #183 from Kuadrant/style-guide
Browse files Browse the repository at this point in the history
Add some contributing notes and a style guide
  • Loading branch information
openshift-merge-bot[bot] authored Jan 24, 2025
2 parents aed4919 + 88719de commit 41afd67
Show file tree
Hide file tree
Showing 3 changed files with 118 additions and 0 deletions.
13 changes: 13 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
The site configuration and navigation layout are defined in [./mkdocs.yml](./mkdocs.yml).
The navigation sections follow the [Diátaxis framework](https://diataxis.fr/), with four main areas:

- Concepts (known as 'Explanation' in Diátaxis)
- APIs & Reference
- Tutorials
- Guides

When adding new documentation, take a moment to consider which area the document belongs to.
You can use the [Diátaxis compass](https://diataxis.fr/compass/) to help answer that question.
If you are unsure, raise an issue, create a PR anyways to invite discussion, or reach out on the [#kuadrant](https://kubernetes.slack.com/archives/C05J0D0V525) slack channel.

When writing content, refer to the [./style_guide.md](./style_guide.md) for writing style guidelines, tips and examples.
4 changes: 4 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,10 @@

This repository contains documentation for Kuadrant, built using MkDocs and the `mike` plugin for multi-versioning. You can run and build these docs using Docker/Podman or by installing MkDocs locally.

## Contributing

See [./CONTRIBUTING.md](./CONTRIBUTING.md)

## Using Docker/Podman

### Running the Docs with Docker
Expand Down
101 changes: 101 additions & 0 deletions style_guide.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
# Style Guide

## Framework

Follow the [Diátaxis approach](https://diataxis.fr/) when you think about and work on new documentation.
This approach helps you decide on what kind of documentation to write and how to write it well.

## Voice

Documents should be written mainly in a combination of "second person" and "active voice", depending on the context.

### Second Person

Address the reader directly, often using "you".
For example, "You need to create a HTTPRoute",
rather than saying "An HTTPRoute needs to be created by you."

### Active Voice

The subject of the sentence performs the action.
For example, "The Gateway controller processes the HTTPRoute to establish routing rules",
rather than saying "The HTTPRoute is processed by the Gateway controller to establish routing rules"

## Tense

Use present tense, unless the meaning is better conveyed in future or past tense.
For example, "This command starts the operator"
rather than "This command will start the operator"

## Language

Use simple and direct language. Avoid unnecessary phrases, such as saying 'please'.
For example, use "To create a ReplicaSet,..." instead of "In order to create a ReplicaSet, ...".
Another example, use "View the pods." instead of "With this next command, we'll view the pods".

## Avoid jargon and idioms

Some readers may not speak English as a primary language. Avoid jargon and idioms to help them understand better.
For example, use "Internally,..." instead of "Under the hood,...",
or "Create a new cluster." instead of "Spin up a cluster."

## Avoid time sensitive statements

Avoid making promises or giving hints about the future. If you need to talk about an alpha feature, put the text under a heading that identifies it as alpha information.
An exception to this would be mentioning the deprecation (and potential eventual removal) of some API.

Avoid statements that will soon be out of date.
An indication of this is words like "currently" and "new." A feature that is new today might not be considered new in a few months.

For example, use "In version 1.0, ..." instead of "In the current version, ...".

## Avoid words that don't add value

Avoid words such as "just", "simply", "easy", "easily", or "simple". These words do not add value.

## Images

Avoid the overuse of images and screenshots as they can be a pain to maintain.

## Characters

Avoid the use of unusual characters, for example Unicode numbering and emojis.

## Grammar

* Start sentences with capital letters and end with . or :
* Products, projects, and tools should be capitalised i.e Kuadrant, Authorino, Limitador etc

## Inline Blocks, Notes & Warnings

To highlight some content like blocks, notes or warnings, use the correct formatting as per https://squidfunk.github.io/mkdocs-material/reference/admonitions/#inline-blocks

For example:

````markdown
```markdown
!!! note

This method currently only works if the Gateway is provided by Istio, with service mesh capabilities enabled across the cluster.
```
````

## Code Blocks

For code blocks preface the language in the code block as per https://squidfunk.github.io/mkdocs-material/reference/code-blocks/#usage

For example:

````markdown
```bash
kubectl get deployments -n kuadrant-system
```
````

## Numbering in lists

Avoid the overuse of numbering. It allows for docs to be updated much easier in the future.

## Environment Variables

Environment variables should be capitalised and use 'KUADRANT_' at the start, for example, `KUADRANT_GATEWAY_NS`, unless they are already defined environment variables for existing tools and services.

0 comments on commit 41afd67

Please sign in to comment.