Publishing guidelines

Content guidelines

The official content (i. e. everything except blog posts) and the CMS Gardener’s Guide are factual publications. Our content helps decision-makers to find the CMS most suitable to their requirements.

Our project does not have the funds for an independent editorial team that would write reviews from a neutral point of view. Therefore we depend on the CMS communities to adapt such a point of view: Take a step back and present the CMS as factual as possible. That includes to be honest about weaknesses as well.

A final editing will happen.

Be prepared for critique. Phrases like the following will be rejected:

• “A CMS suitable to create websites of any size” - sorry, that goes without saying. All participating CMS are that mature.
• Easy and intuitive to use" - too biased. Apart from every CMS community believing their system to be intuitive, it totally depends on the user’s former experience.
• “$CMS has become the most popular CMS during the last years” - not provable.
• Superlatives of any kind (best, perfect, most appealing …) - just don’t use.
• Listings - avoid. We want full sentences. Only use lists when reasonable.
• Technical terms Bingo - those intimidate the readers and more often than not hide that there’s no real value included.
• Don’t address the readers directly. Instead of “You can …” write “Editors can” or “Administrators will value …”

Advice for good style

Understanding target groups. Especially the Gardener’s Guide addresses people who know how to use the internet but are no IT experts. We try to write texts that our parents or grandparents can follow.

The only exception is the “Technology” section. This will rather address people in the decision-makers’ IT department.

Explain technical terms. We have a glossary for a reason. There will also be a CMS-specific glossary in the near future (explaining the individual usage of “module”, “extension”, “plugin” for example).

Nevertheless we try to explain technical terms where they appear, i. e. in the copy text itself.

Look for unique features. What sets your CMS apart from all the others? ScientificCMS for example has been optimized for scientific usage by collecting feedback especially from that target group.

Name weaknesses. Openness creates trust. If you try to hide what you think could create a negative image, will come back as distrust. There will always be decision-makers that find the mentioned weaknesses uncritical if only they can trust the other features.

Read three of the current chapters. At least. This will help you adapt your style of writing to the book.

Translate with care. Avoid word-by-word translations. Write sentences that convey the same meaning. Please have a native speaker review the translation.

Bilingual

We are aiming at publishing in English along with a German translation (or vice versa). Translation is mandatory for the CMS Gardener's Guide.

Gendering

One of our scopes is to raise diversity in our industry. Writing gender-aware is more of an issue in the German translations but please be aware of the topic.

• If you mention an “administrator”, avoid translating to “he”. In most cases the plural will be helpful (“administrators” / “they”).
• If unavoidable, use “she” and “he” in a way that bypasses clichés. An administrator persona would be female, an editor persona would be male, for example.
• Have in mind that there are non-binary genders. They might identify with neither “he” nor “she”.

Imprint and license

By contributing you agree that content is published under a Creative Commons license (CC BY-SA = attributed to author, shared alike).

Therefore add all the profiles/names that provided relevant parts of the content. When reviewing given content: remove names if authorship for current version is not given any longer.

All contributors will be updated in every printed issue's imprint of the CMS Gardener's Guide.

Illustrations

Illustrations motivate readers to invest time in reading.

Along with the CMS chapters we want to show lighthouse projects and the CMS's graphical user interface (GUI). Be prepared that because of print layout reasons not all your provided screenshots may be used or not at the position indicated.

Required for CMS portraits

• at least 3 meaningful and possibly diverse screenshots of the back-end GUI
• 4-6 screenshots (without browser frame) of lighthouse projects that have been built with your CMS. Make sure you don’t break any NDA or copyright (e. g. get written consent for showing intranet screenshots and make sure no real personal data is leaked).

File type/size

• Any web image format, width min 1280 pixel
• Aspect ratio ideally 16/9, do not exceed 16/36 please

File names

Your uploaded assets will be downloaded for print production as well. Please spare us time by providing meaningful file names:

• [CMS]_yyyy_[project-shortname].[ext] - Sample project
• [CMS]-[version-no]_yyyy_Backend-[keyword].[ext] - Back-end screenshots

No spaces and just the one dot (followed by the file extension) please.

Alternative text and captions

We want this website to be as accessible as possible for everyone.

When uploading an image, the alternative text is mandatory. Please provide a meaningful description for any illustration or photography. Exception: logos may be described as "XY logo".

Imagine this were a radio show and the moderator would keep saying "some image". Not nice. Do not bypass this with "illustration: screenshot" or "event photo". And do not copy the file name here!

Captions should not repeat the alternative text and vice versa. Captions will be used in print and show up beneath the image wherever selected.

Licenses

Please note that we respect copyright. Peferably use images under a Creative Commons license (or similar). We have a widget to easily enter the license information. In case you cannot find out, the widget defaults to "all rights reserved" and still allows to (optionally) enter the creator and source.

Related information

When updating a CMS chapter, please check carefully if the following need an update, too:

• The web links always relate to the language version. Make sure you list the most relevant first (and confine to the most relevant URLs that help channelling the readers to software and community entry points).
• Associations list: Please check if the entry of your official association (local, international) is still is up to date (address) - or if it’s still missing (then add, please). We are publishing all not-for-profit associations, no matter if they are CMS Garden members or not.
• Abbreviations and Glossary: In case you have used an abbreviation that is not yet in the list, please add. Have you introduced a technical term that might be unknown to a broad public? Please add. If you feel uncomfortable with explaining that term, add it nevertheless. The editorial team will try and help.