Contribute to our documentation

Contributing to documentation is a great way to get started as a contributor to open-source projects, no matter your level of experience.

We welcome, encourage and appreciate contributions from our user community in the form of suggestions, fixes and constructive feedback. Whether you are new to Ceph and want to highlight something you found confusing, or you’re an expert and want to create a “how-to” guide to help others, we will be happy to work with you to make our documentation better for everybody.

Leave a comment on the Discourse forum post or talk to us on our Matrix channel.

We hope to make it as easy as possible to contribute. If you feel something is unclear, wrong, or broken, please don’t hesitate to leave a comment in the Matrix room.

Editing on Discourse

The Charmed Ceph documentation is published via our Discourse forum hosted at https://discourse.ubuntu.com/.

Every documentation page is published from an equivalent doc category forum post. Each forum post can be accessed from the Help improve this document in the forum link at the bottom of every page of our documentation.

Feel free to improve any documentation topic; pages are freely editable within the forum itself. Just click on the Edit button at the bottom of the documentation article forum post:

Documentation is written in the Markdown format supported by Discourse.

Mostly, you don’t need to worry about the syntax. You can simply use the style toolbar in the Discourse topic editing window to mark the elements you need.

New users

If you are a new Discourse user, your capabilities will be temporarily limited. Discourse uses a trust system that grants experienced users more rights over time. New users start at Trust Level 0, but quickly get to Trust Level 1 where all new user restrictions are removed and they can create and edit our documentation freely.

Trust Level 1 is attained by:

• Entering at least 5 topics
• Reading at least 30 posts
• Spending a total of 10 minutes reading posts

Users at Trust Level 1 can:

• Edit wiki posts
• Use all core Discourse functions; all new user restrictions are removed
• Send private messages
• Upload images and attachments
• Flag posts to alert moderators
• Mute other users

Diátaxis

Our documentation content, style and navigational structure follows the Diátaxis systematic framework for technical documentation authoring. This framework splits documentation pages into tutorials, how-to guides, reference material and explanatory text:

• Tutorials are lessons that accomplish specific tasks through doing. They help with familiarity and place users in the safe hands of an instructor.
• How-to guides are recipes, showing users how to achieve something, helping them get something done. A How-to has no obligation to teach.
• Reference material is descriptive, providing facts about functionality that is isolated from what needs to be done.
• Explanation is discussion, helping users gain a deeper or better understanding of Charmed Ceph, as well as how and why Charmed Ceph functions as it does.

To learn more about our Diátaxis strategy, see Diátaxis, a new foundation for Canonical documentation.

Improving our documentation and applying the principles of Diátaxis are on-going tasks. There’s a lot to do, and we don’t want to deter anyone from contributing to our docs. If you don’t know whether something should be a tutorial, how-to, reference doc or explanatory text, either ask on the forum or publish in the category you think is best. Changes are easy to make, and every contribution helps.

Open Documentation Academy

Charmed Ceph is a proud member of the Canonical Open Documentation Academy (CODA), an initiative led by the documentation team at Canonical to provide help, advice, mentorship, and dozens of different tasks to get started on, within a friendly and encouraging environment.

A key aim of this initiative is to help lower the barrier into successful open-source software contribution, by making documentation into the gateway, and it’s a great way to make your first open source documentation contributions to Charmed Ceph.

But even if you’re an expert, we want the academy to be a place to share knowledge, a place to get involved with new developments, and somewhere you can ask for help on your own projects.

The best way to get started is with our task list . Take a look, bookmark it, and see our Getting started guide for next steps.

Stay in touch either through the task list, or through one of the following locations:

• Our discussion forum on the Ubuntu Community Hub.
• In the Matrix room for interactive chat.
• Follow us on Fosstodon for the latest updates and events.

If you’d like to ask us questions outside of our public forums, feel free to email us at [email protected].

In addition to the above, we have a weekly Community Hour starting at 16:00 UTC every Friday. Everyone is welcome, and links and comments can be found on the forum post.

Finally, subscribe to our Documentation event calendar. We’ll expand our Community Hour schedule and add other events throughout the year.

Agreements

Everyone involved with CODA needs to follow the words and spirit of the Ubuntu Code of Conduct v2.0. By participating, you implicitly agree to abide by this code of conduct.

If this is the first time you are contributing to a Canonical project, you will need to sign the Canonical Contributor Licence Agreement before your contribution can be considered for inclusion within our project. If you have already signed it, e.g. when contributing to another Canonical project, you do not need to sign it again.

This licence protects your copyright over your contributions, including the right to use them elsewhere, but grants us (Canonical) permission to use them in our project.

Identifying suitable task

The academy uses issue labels to give the contributor a glimpse into the task and what it requires, including the type of task, skills or level of expertise required, and even the size estimation for the task. You can find tasks of all sizes in the academy issues list.

From small tasks, such as replacing outdated terminology, checking for broken links, testing a tutorial or ensuring adherence to the Canonical documentation style guide; to medium-sized tasks like, converting documentation from one format to another, or migrating the contents of a blog post into the official documentation; to more ambitious tasks, such as adding a new How-to guide, restructuring a group of documents, or developing new tests and automations.

Completing and closing tasks

When a task has been completed to your satisfaction, we’ll ask the contributor whether they would prefer to merge their work into your project themselves, or leave this to the project.

Recognition

After successfully completing a task, we’ll give credit to the contributor and share their success in our forums, on the pages themselves, and in our news updates and release notes.

Guidance for writing

Consistency of writing style in documentation is vital for a good user experience. To accommodate our audience with a huge variation in experience, we:

• write with our target audience in mind
• write inclusively and assume very little prior knowledge of the reader
• link or explain phrases, acronyms and concepts that may be unfamiliar, and if unsure, err on the side of caution
• adhere to the style guide

Language

Canonical previously used British (GB) English, so you may notice that older documentation is in this format. However, we have recently switched to US English. It’s a good idea to set your spellchecker to en-US; which will pick up most of of the inconsistencies. If it doesn’t, they will be picked up in review by the documentation team.

There are many small differences between UK and US English, but for the most part, it comes down to spelling.
Some common differences are:

• the ize suffix in preference to ise (e.g. capitalize rather than capitalise)
• our instead of or (as in color and colour)
• licence as both a verb and noun
• catalog rather than catalogue
• dates take the format 1 January 2013, 1-2 January 2025 and 1 January - 2 February 2025

Acronyms

Acronyms should always be capitalized.

They should always be expanded the first time they appear on a page, and then can be used as acronyms after that. E.g. OSD should be shown as Object Storage Daemon (OSD), and then can be referred to as OSD for the rest of the page.

Links

The first time you refer to a package or other product, you should make it a link to either that product’s website, or its documentation, or its manpage.

Links should be from reputable sources (such as official upstream docs). Try not to include blog posts as references if possible. And, always verify that the links are correct and accurate.

Try to use inline links sparingly. If you have a lot of useful references you think the reader might be interested in, feel free to include a “Further reading” section at the end of the page.

Writing style

Try to be concise and to-the-point in your writing.

It’s alright to be a bit light-hearted and playful in your writing, but please keep it respectful, and don’t use emoji (they don’t render well in documentation, and may not be deemed professional).

It’s also good practice not to assume that your reader will have the same knowledge as you. If you’re covering a new topic (or something complicated) then try to briefly explain, or link to supporting explanations of, the things the typical reader may not know, but needs to (refer to the Diátaxis framework to help you decide what type of documentation you are writing and the level and type of information you need to include, e.g. a tutorial may require additional context but a how-to guide can skip some foundational knowledge - it is safer to assume some prior knowledge).

Markdown elements

Sections and headings

Avoid skipping header levels in your document structure, i.e., a level 2 header (##) should be followed by a level 3 sub-header (###) not level 4.

# Heading level 1

## Heading level 2

### Heading level 3

#### Heading level 4

Always include some text between headers if you can. You can see this demonstrated between this section’s heading and the one above it (Markdown elements). It looks quite odd without text to break the headers apart!

Lists

For a numbered list, use 1. in front of each item. The numbering will be automatically rendered, so it makes it easier for you to insert new items in the list without having to re-number them all:

1. This is the first item

1. This is the second

1. This is the third

Unless a list item includes punctuation, don’t end it with a full stop. If one item in a list needs a full stop, add one to all the items in that list.

Code blocks

Enclose a code block with three backticks:

  ```yaml

  Some code block here

Use separate command input blocks from command output blocks. We do this because we have a “copy to clipboard” feature in the documentation, and it’s more convenient for the reader to copy the code if it only contains the input.

Avoid using a command line prompt (e.g. $ or #) in an input block if possible, and precede the output block with some kind of text that explains what’s happening. For example:

Juju list models

Produces the following output:

Model     	Cloud/Region     	Type  Status 	Machines  Units  Access  Last connection

ceph-charms\*  localhost/localhost  lxd   available     	3  	3  admin   15 minutes ago

controller	localhost/localhost  lxd   available     	1  	1  admin   just now

It can also be helpful to orient the reader with what they should be seeing if you can include examples.

Use a single backtick to mark inline commands and other string literals, like paths/to/files.