Skip to main content
Every project documented in the Clubedge documentation portal has its own technical structure and sources of truth. The documentation should reflect the project as it actually exists rather than assuming every project uses the same stack or repository layout.

​
Properties

​
README.md

The project’s root README.md is the first reference when documenting a project. It should explain what the project does, how to get started, the main development workflow, and where developers can find deeper technical documentation. Example:

​
package.json

Node.js projects normally use package.json as the source of truth for scripts, dependencies, package metadata, and package-manager configuration. Use it when documenting installation, development, testing, building, linting, and other project commands. Examples:

​
OpenAPI

Backend projects may expose an OpenAPI specification that defines their HTTP API. When available, use the project’s OpenAPI specification as the source of truth for endpoints, authentication, parameters, request bodies, responses, and schemas. Common locations include:

​
Environment configuration

Projects may provide example environment files or configuration documentation for required runtime variables. Never document real secrets or credentials. Use placeholders and reference the project’s environment configuration when needed. Examples:

​
Monorepo

Some Clubedge projects are organized as monorepos containing multiple applications, packages, SDKs, or shared tooling. Documentation should clearly identify whether a command applies to the repository root, a specific application, or a specific package. Examples:

​
Project documentation

Projects may contain additional documentation files for architecture, decisions, workflows, deployment, or technical details. Use the existing project documentation as source material instead of duplicating information that is already maintained by the project. Examples:
Documentation navigation should reflect what developers need to find, not simply mirror the project’s filesystem. Product documentation can be grouped by product while shared documentation remains available independently. Example:

​
Product

Each product gets its own documentation area inside the shared Clubedge documentation portal. Product pages should contain information specific to that product, including its concepts, setup, workflows, APIs, SDKs, and integrations. Example:

​
Guides

Guides contain documentation that applies to the documentation workflow or to multiple projects rather than to one product. Examples:

​
SDK documentation

Products that expose SDKs should document each supported runtime or framework separately when the integration differs. Example:

​
API

API documentation should be included when a project exposes a backend API. Prefer using the project’s OpenAPI specification to generate or maintain API reference documentation so the documented contract stays aligned with the implementation.
OpenAPI file pathA path to the OpenAPI specification maintained by the project.Example: openapi/v1/openapi.yamlOpenAPI URLA URL pointing to a published OpenAPI specification when the project exposes one.Example: https://api.example.com/openapi/v1/openapi.json

​
Repository

Documentation should link technical information back to the project repository when developers need to inspect the implementation. The repository is especially useful for verifying current scripts, dependencies, configuration, source structure, and implementation details. Example:

​
Source of truth

Technical documentation should always be based on the current project implementation and its maintained configuration. Use the appropriate source depending on what you are documenting.

​
Versions

When a project has multiple supported versions, document version-specific behavior clearly. Examples:

​
Branding

Product documentation should use the product’s established terminology, naming, and visual identity while remaining part of the shared Clubedge documentation portal. The shared portal should not force every product to have identical technical content.

​
Feedback

Documentation should make it easy for developers to report incorrect, outdated, or missing technical information. Feedback should be actionable and tied to the relevant product, page, API contract, SDK, or repository when possible.

​
Mode toggle

Documentation should remain readable in both light and dark themes. Code examples, diagrams, screenshots, and other visual content should be checked in both modes when they are used.

​
Background image

Product documentation may use product-specific visual assets when they improve understanding, but technical content should remain clear without relying on decorative backgrounds or visual effects.