Help Center
< All Topics
Print
Posted
Updated
Byadmin

MinistryCentral Europe

1. Purpose of This Document

These guidelines define how documentation should look and read across MinistryCentral Europe.

They exist to:

  • Ensure consistency across contributors and editors
  • Reduce editorial guesswork
  • Improve readability and trust
  • Make documents easier to maintain over time

These guidelines apply to:

  • Echo Knowledge Base articles
  • Documentation prepared in Notion for publication
  • Onboarding guides and operational documentation

They do not override governance or authority rules.

2. General Writing Principles

Clarity Over Cleverness

  • Prefer simple, direct language
  • Avoid jargon unless it is defined
  • Assume a mixed audience (technical and non-technical)

Consistency Over Style

  • Use the same terms for the same concepts
  • Do not introduce synonyms for variety
  • Align with existing canonical terminology

Instruction Over Explanation (When Appropriate)

  • For procedures: explain what to do
  • For governance: explain why it exists
  • Avoid mixing the two in the same section

3. Tone & Voice

Required Tone

  • Calm
  • Professional
  • Respectful
  • Confident but not authoritarian

Avoid

  • Casual language (“just”, “simply”, “obviously”)
  • Apologetic phrasing
  • Marketing language
  • Emotional or corrective tone

Preferred Voice

  • Second person (“you”) for guides
  • Declarative statements for governance
  • Neutral framing for rules and constraints

4. Document Structure Standards

Headings

  • Use clear, descriptive headings
  • Avoid clever or metaphorical titles
  • Keep heading hierarchy logical (H2 → H3 → H4)

Example:

## Purpose
## Scope
## Workflow
### Step 1 — Drafting

Paragraphs

  • Keep paragraphs short (3–5 lines max)
  • One idea per paragraph
  • Break long explanations into lists

Lists

Use lists when:

  • Explaining steps
  • Defining rules
  • Clarifying options

Use:

  • Bullets for unordered items
  • Numbers for sequences

Avoid nested lists deeper than two levels.

5. Emphasis & Formatting

Bold

Use bold for:

  • Key rules
  • Non-negotiables
  • Section anchors

Do not overuse.

Italics

Use italics for:

  • Clarifications
  • Secondary emphasis
  • Short explanatory notes

Callouts / Warnings (When Available)

Use sparingly for:

  • Critical warnings
  • Common mistakes
  • Escalation points

Example:

❗ If you are unsure whether a change is substantive, escalate before editing.

6. Terminology Rules

Capitalization

Capitalize:

  • Defined roles (Content Editor, Contributor, Platform Lead)
  • Canonical document titles
  • Lifecycle stages (Draft, Review, Approved, Canonical)

Do not capitalize generic nouns unnecessarily.

Consistent Terms (Examples)

  • Echo Knowledge Base (not “the KB”, except informally)
  • Canonical (not “final”, “official”, or “published”)
  • Approval (not “sign-off”)
  • Draft (not “working version”)

If a term matters, use it consistently.

7. Links & References

Internal References

  • Refer to other documents by full title
  • Links may be added later if platform constraints exist
  • Do not rely on links alone to convey meaning

Example:

See

Status Lifecycle & Canonical Rules

External Links

  • Use only when necessary
  • Prefer official or stable sources
  • Avoid linking to transient or personal content

8. Images, Diagrams & Media

When to Use Visuals

  • To explain workflows
  • To show structure
  • To reduce cognitive load

Do not use images decoratively.

Captions

Always include a short caption explaining:

  • What the image shows
  • Why it matters

9. Version Notes & Updates

For canonical documents:

  • Add a short “Last updated” note when meaningful
  • Do not maintain full changelogs unless required
  • Major changes should be referenced in Change Management

10. Editorial Checklist (Quick Reference)

Before publishing, ask:

  • Is the structure clear?
  • Is terminology consistent?
  • Is the tone appropriate?
  • Could a non-expert understand this?
  • Does this align with existing canonical documents?

If any answer is “no”, revise before publishing.

11. Relationship to Other Documents

These guidelines support:

  • Documentation Contribution Guide
  • Content Editor Playbook
  • Notion → KB Publishing Rules

They do not define authority or workflow.

12. Summary

  • Consistency builds trust
  • Clarity reduces friction
  • Editors are stewards of readability
  • Style exists to serve meaning — not override it

Table of Contents
Scroll to Top