Help Center
< All Topics
Print
Posted
Updated
Byadmin

MinistryCentral Europe

This document defines the standard workflow for creating, reviewing, approving, and publishing documentation within MinistryCentral Europe.

It describes how work moves, not who holds authority or when content becomes canonical. Those aspects are defined in:

  • Canonical Authority Model
  • Status Lifecycle & Canonical Rules
  • Change Management Rules

This workflow applies to all documentation, including onboarding guides, governance documents, instructional material, and operational references.

1. Purpose

The Documentation Workflow exists to:

  • Enable safe, distributed contribution
  • Ensure consistent review and approval
  • Prevent accidental publication or authority drift
  • Provide clarity on where work happens at each stage
  • Reduce friction for contributors and editors

It answers the question:

“What is the next step, and where does it happen?”

2. Core Workflow Principle

Work flows forward through defined stages; authority is applied at specific transition points.

No single tool or role completes the entire workflow alone.

3. Standard Workflow Overview

All documentation follows this sequence:

  1. Idea / Proposal
  2. Drafting
  3. Review
  4. Approval
  5. Canonical Publication
  6. Maintenance or Change

Each stage has:

  • A primary location
  • Clear role ownership
  • Explicit exit conditions

4. Workflow Stages (Detailed)

Stage 1 — Idea / Proposal

Purpose: Capture intent and scope

Where it happens:

  • Informal notes
  • Notion pages
  • Email
  • Conversation summaries

Who participates:

  • Contributors
  • Editors
  • Coordinators
  • Instructors

Rules:

  • No formal structure required
  • No authority implied
  • Ideas may be discarded freely

Exit condition:

  • Decision to proceed with drafting

Stage 2 — Drafting

Purpose: Create working content

Where it happens:

  • Notion (preferred)
  • Word or other editors (acceptable)

Who participates:

  • Contributors
  • Editors
  • Subject-matter authors

Rules:

  • Content must be clearly marked as Draft
  • Meaning may evolve freely
  • Multiple iterations are expected
  • No publication to Echo KB

Exit condition:

  • Content is substantively complete and ready for review

Stage 3 — Review

Purpose: Evaluate quality, alignment, and correctness

Where it happens:

  • Notion (comments, revisions)
  • Designated review environment

Who participates:

  • Content Editors
  • Coordinators or Leads
  • Subject authorities (as needed)

Rules:

  • Feedback must be visible or documented
  • Review focuses on:
    • Clarity
    • Consistency
    • Alignment with governance
  • Content remains non-canonical

Exit condition:

  • Consensus that content is ready for approval

Stage 4 — Approval

Purpose: Apply canonical authority

Where it happens:

  • Explicit confirmation by authorized role
  • Documented via status, note, or record

Who participates:

  • Role holders defined in the Canonical Authority Model

Rules:

  • Approval must be explicit
  • Approval freezes meaning
  • Approval does not automatically publish content

Exit condition:

  • Content is approved and eligible for canonical residence

Stage 5 — Canonical Publication

Purpose: Establish official reference

Where it happens:

Who participates:

  • Editors (publication)
  • Platform / Admin roles (system integrity)

Rules:

  • Echo KB is the primary canonical residence
  • Published content must reflect the approved version exactly
  • Any discrepancy must be corrected immediately

Exit condition:

  • Content is live and authoritative

Stage 6 — Maintenance or Change

Purpose: Sustain accuracy over time

Where it happens:

  • Monitoring in Echo KB
  • Proposed changes drafted in Notion

Who participates:

  • Editors
  • Coordinators
  • Platform roles (as applicable)

Rules:

  • Non-substantive fixes may be applied carefully
  • Substantive changes must follow:→ Change Management Rules
  • Deprecated content must be clearly marked

Exit condition:

  • Content remains current, or
  • Content is superseded or archived

 

5. Tool Usage Summary

Stage Primary Tool Notes
Idea Any Informal
Drafting Notion Preferred
Review Notion Comments & revisions
Approval Role-based Explicit
Canonical Echo KB Authoritative
Change Notion → Echo KB Controlled

Tools support the workflow; they do not define authority.

6. Common Failure Modes (Avoid These)

  • Publishing drafts to Echo KB
  • Treating editing as approval
  • Making silent changes to canonical content
  • Maintaining parallel “official” copies
  • Skipping review for “small changes”

If any of these occur, revert to the lifecycle and change rules immediately.

7. Relationship to Other Documents

This workflow operates in conjunction with:

  • Canonical Authority Model – defines who may approve
  • Status Lifecycle & Canonical Rules – defines content states
  • Change Management Rules – governs post-publication changes
  • Documentation Contribution Guide – explains how to participate

In case of ambiguity, authority and lifecycle rules take precedence.

8. Summary

  • Ideas are free
  • Drafts are flexible
  • Review is intentional
  • Approval is explicit
  • Echo KB is authoritative
  • Change is controlled

Good documentation flows forward.

Good governance ensures it doesn’t drift.

Table of Contents
Scroll to Top