WEP Digital Hub: Content Strategy
Purpose
This document is the single source of truth for contributors of the WEP Digital Hub portal. It defines what content belongs here, how it is organized, and where to find (or link to) content that lives elsewhere.
The goal is to provide a clear, unambiguous direction so that every contributor — human or AI — knows exactly where to place new documentation.
What Belongs in This Repository
The WEP Digital Hub contains technical and architectural documentation for the WEP digital ecosystem. Specifically:
✅ In scope
| Content type | Example | Section |
|---|---|---|
| System architecture and context maps | Ecosystem overview, DDD bounded contexts | 01-Architecture/ |
| Business processes and procedures | Onboarding, offboarding, service management | 02-Processes/ |
| Security policies and incident response | IT Policy, AI Policy, access control | 03-Security/ |
| System documentation (internal apps) | Backend WEP, custom tools | 04-Systems/01-Internal-Apps/ |
| System documentation (third-party SaaS) | Zoho, Office365, JustCall, 1Password | 04-Systems/02-Third-Party-SaaS/ |
| Infrastructure documentation | Network, hosting, deployment | 04-Systems/03-Infrastructure/ |
| Governance and meta-documentation | ADRs, glossary, guidelines, roadmap | 00-Meta/ |
❌ Out of scope
| Content type | Where it belongs |
|---|---|
| End-user documentation (student/parent guides) | Dedicated user-facing platform |
| Marketing content | Marketing team tools |
| Contracts and legal documents | Legal / document management system |
| Source code | Respective code repositories |
| Meeting notes and ephemeral communications | Collaboration tools (Slack, email) |
Note: Out-of-scope content may still be linked from within the portal as external references (e.g., a system page linking to the vendor's user guide, or a process page linking to a legal document). The principle is: host the technical context here, link to the authoritative source elsewhere.
What Gets Linked (Not Duplicated)
Some content lives in external systems and should be linked, not copied. This avoids duplication and ensures the source of truth remains where the content is maintained.
External resources to link
| Resource type | Example | How to link |
|---|---|---|
| Architecture diagrams | Miro boards | Embed image + link to live board |
| Monitoring dashboards | Status page, uptime tools | Link in 04-Systems/ relevant page |
| Code repositories | Backend WEP, Website WEP | Link in 04-Systems/01-Internal-Apps/ |
| Vendor documentation | Zoho API docs, Office365 admin | Link in the relevant SaaS page |
| Module-specific documentation | Backend WEP docs, Website WEP docs | Link in 04-Systems/01-Internal-Apps/ |
Future expansion
As individual projects (Backend WEP, Website WEP, etc.) develop their own documentation, their entry in 04-Systems/01-Internal-Apps/ should serve as a landing page with:
- A brief description of the system
- Links to the project's own documentation repository or site
- Key integration points with other WEP systems
Repository Structure
wep-digital-hub/
├── 00-Meta/ # Governance, guidelines, ADRs, glossary
│ ├── 01-Guidelines/ # Operational guides for contributors
│ ├── 02-Templates/ # Document templates
│ ├── 03-Legal/ # Compliance references
│ ├── 04-ADR/ # Architecture Decision Records
│ └── 05-Debates/ # Strategic discussion records
├── 01-Architecture/ # System architecture and design
├── 02-Processes/ # Business processes and SOPs
├── 03-Security/ # Security policies and procedures
├── 04-Systems/ # System-specific documentation
│ ├── 01-Internal-Apps/ # WEP-built applications
│ ├── 02-Third-Party-SaaS/ # External SaaS platforms
│ ├── 03-Infrastructure/ # Network, hosting, servers
│ └── 04-Legacy/ # Deprecated or migrating systems
├── docs-portal/ # Docusaurus configuration (NOT content)
└── .agent/ # Agentic governance (rules, workflows, skills)
Adding a new top-level section
Top-level sections (e.g., 05-NewSection/) should be rare and require an ADR. If you believe new content doesn't fit existing sections, discuss with the Architect first.
When adding a section, you must update:
- The
includearray indocs-portal/docusaurus.config.js - The sidebar config in
docs-portal/sidebars.js - This document
Adding content within existing sections
Simply create a .md file (or subdirectory with a README.md) in the appropriate section. Docusaurus auto-generates the sidebar from directory structure.
Conventions (Quick Reference)
These are intentionally brief — follow the links for full details.
| Rule | Reference |
|---|---|
Every .md file must have YAML frontmatter (slug, title, last_modified) | ADR-001 |
| All content in English; internal docs may use Italian with English summary | ADR-004 |
| Use consistent terminology from the glossary | Glossary |
Work on feature branches, never directly on main | ADR-003 |
Document Lifecycle (Quick Reference)
| Phase | What happens | Reference |
|---|---|---|
| Create | Work on a feature branch (docs/, feat/, fix/) | Collaboration Workflow |
| Review | Open a PR targeting main, tag reviewers | Collaboration Workflow |
| Track | Update ROADMAP.md when completing milestones | ROADMAP |
| Archive | Deprecated content moves to 04-Legacy/ with a deprecation notice | — |