Some checks are pending
Go Benchmark / Performance Regression Check (push) Waiting to run
Cerberus Integration / Cerberus Security Stack Integration (push) Waiting to run
Upload Coverage to Codecov / Backend Codecov Upload (push) Waiting to run
Upload Coverage to Codecov / Frontend Codecov Upload (push) Waiting to run
CodeQL - Analyze / CodeQL analysis (go) (push) Waiting to run
CodeQL - Analyze / CodeQL analysis (javascript-typescript) (push) Waiting to run
CrowdSec Integration / CrowdSec Bouncer Integration (push) Waiting to run
Docker Build, Publish & Test / build-and-push (push) Waiting to run
Docker Build, Publish & Test / Security Scan PR Image (push) Blocked by required conditions
Quality Checks / Auth Route Protection Contract (push) Waiting to run
Quality Checks / Codecov Trigger/Comment Parity Guard (push) Waiting to run
Quality Checks / Backend (Go) (push) Waiting to run
Quality Checks / Frontend (React) (push) Waiting to run
Rate Limit integration / Rate Limiting Integration (push) Waiting to run
Security Scan (PR) / Trivy Binary Scan (push) Waiting to run
Supply Chain Verification (PR) / Verify Supply Chain (push) Waiting to run
WAF integration / Coraza WAF Integration (push) Waiting to run
1.7 KiB
Executable File
1.7 KiB
Executable File
description, applyTo
| description | applyTo |
|---|---|
| Guidance for writing and formatting the `docs/features.md` file. | docs/features.md |
Features Documentation Guidelines
When creating or updating the docs/features.md file, please adhere to the following guidelines to ensure clarity and consistency:
Structure
- This document should provide a short, to the point overview of each feature. It is used for marketing of the project. A quick read of what the feature is and why it matters. It is the "elevator pitch" for each feature.
- Each feature should have its own section with a clear heading.
- Use bullet points or numbered lists to break down complex information.
- Include relevant links to other documentation or resources for further reading.
- Use consistent formatting for headings, subheadings, and text styles throughout the document.
- Avoid overly technical jargon; the document should be accessible to a broad audience. Keep novice users in mind.
- This is not the place for deep technical details or implementation specifics. Keep those for individual feature docs.
Content
- Start with a brief summary of the feature.
- Explain the purpose and benefits of the feature.
- Keep descriptions concise and focused.
- Ensure accuracy and up-to-date information.
Review
- Changes to `docs/features.md` should be reviewed by at least one other contributor before merging.
- Review for correctness, clarity, and consistency with the guidelines in this file.
- Confirm that each feature description reflects the current behavior and positioning of the project.
- Ensure the tone remains high-level and marketing‑oriented, avoiding deep technical implementation details.